11# Publishing Guide for Maintainers
22
33This document describes how to publish the ` @hypercerts-org/lexicon `
4- package to npm using GitHub Actions workflows with Changesets. All
5- publishing workflows are manually triggered to give you full control
6- over when releases are made.
4+ package to npm using GitHub Actions workflows with Changesets. The
5+ workflow uses separate branches for beta and stable releases, with all
6+ releases manually triggered to give you full control over when releases
7+ are made.
8+
9+ ## Branch Strategy
10+
11+ - ** ` develop ` branch** : Beta/prerelease versions
12+ - ** ` main ` branch** : Stable releases
13+
14+ ** Suggested Flow:** ` feature ` → ` develop ` (beta) → ` main ` (stable)
15+
16+ ** Note:** Direct development on ` main ` is also supported. The ` develop ` → ` main ` flow is suggested when you want to publish beta versions for testing before stable releases. If you work directly on ` main ` , you can skip the beta testing phase and go straight to stable releases.
17+
18+ ### Release Flow
19+
20+ ``` text
21+ ┌──────────────────────────────────────────────────────────────────┐
22+ │ │
23+ │ feature/* ──────────────────┐ │
24+ │ │ │ │
25+ │ │ npm run changeset │ PR │
26+ │ │ (describe changes) │ │
27+ │ ▼ ▼ │
28+ │ ┌─────────┐ merge ┌──────────┐ │
29+ │ │ commit │ ────────► │ develop │ ──► Manual publish @beta │
30+ │ │ + .md │ └────┬─────┘ (0.9.0-beta.1) │
31+ │ └─────────┘ │ │
32+ │ │ PR (after: npm changeset pre exit) │
33+ │ ▼ │
34+ │ ┌────────┐ │
35+ │ │ main │ ──► Creates "Release PR" │
36+ │ └────┬───┘ │
37+ │ │ │
38+ │ │ merge Release PR │
39+ │ ▼ │
40+ │ ┌──────────────┐ │
41+ │ │ npm publish │ ──► @latest (0.9.0) │
42+ │ └──────────────┘ │
43+ │ │
44+ └──────────────────────────────────────────────────────────────────┘
45+ ```
746
847## Prerequisites
948
1049Before publishing, ensure you have:
1150
12- 1 . ** GitHub Secrets configured:**
13- - ` RELEASE_PAT ` : GitHub Personal Access Token with permissions to bypass
14- branch protection rules. Required for the beta release workflow that
15- commits and pushes version changes to protected branches.
16- - ** Recommended:** Fine-grained Personal Access Token
17- - Create at: < https://github.com/settings/tokens?type=beta >
18- - Repository access: Select this repository
19- - Repository permissions: ` Contents ` (read and write), ` Metadata `
20- (read-only)
21- - ** Alternative:** Classic Personal Access Token (if fine-grained
22- doesn't work with your branch protection settings)
23- - Create at: < https://github.com/settings/tokens >
24- - Required scopes: ` repo ` (full control of private repositories)
25- - This is needed because ` GITHUB_TOKEN ` cannot bypass branch protection
26- - ** Note:** Ensure branch protection rules allow the token to bypass
27- protection (uncheck "Do not allow bypassing the above settings" or
28- add the token as an allowed actor)
29- - ` NPM_TOKEN ` : npm access token with publish permissions for
30- ` @hypercerts-org ` scope
51+ 1 . ** npm Trusted Publisher configured:**
52+ - The workflow uses npm Trusted Publishers via GitHub OIDC for secure,
53+ token-less publishing
54+ - Configure on npmjs.com: Package settings → Publishing access → Add a
55+ GitHub Actions publisher
56+ - Workflow name: ` Release `
57+ - See: < https://docs.npmjs.com/trusted-publishers >
58+ - No ` NPM_TOKEN ` secret is required
3159
3260## Adding Changesets
3361
@@ -49,66 +77,83 @@ This will:
4977collisions when multiple contributors create changesets simultaneously.
5078The filename doesn't affect version ordering—Changesets uses git history
5179to determine the order of changes. You can rename these files if desired,
52- but it's not necessary and not recommended in collaborative environments .
80+ but it's not necessary.
5381
5482## Publishing a Stable Release
5583
84+ ** If merging from ` develop ` → ` main ` :** Before merging, you must exit prerelease mode on the ` develop ` branch:
85+
86+ ``` bash
87+ # On develop branch
88+ npm run changeset pre exit
89+ git add .changeset/pre.json
90+ git commit -m " chore: exit prerelease mode"
91+ git push
92+ ```
93+
94+ This sets the exit intent in ` pre.json ` , which is required before merging to ` main ` . The PR check will verify this.
95+
96+ ** If working directly on ` main ` :** You can skip this step since ` pre.json ` won't exist.
97+
5698To publish a stable release to npm:
5799
58- 1 . ** Navigate to GitHub Actions:**
59- - Go to the repository on GitHub
60- - Click on the "Actions" tab
100+ 1 . ** If merging from ` develop ` → ` main ` :**
101+ - Run ` npm run changeset pre exit ` on ` develop ` branch
102+ - Commit and push the change
103+ - Merge ` develop ` → ` main ` (the PR check will verify exit intent)
61104
62- 2 . ** Select the workflow :**
63- - Choose "Release" from the workflow list
105+ ** If working directly on ` main ` :**
106+ - Skip this step and proceed to step 2
64107
65- 3 . ** Run the workflow:**
108+ 2 . ** Run the workflow:**
109+ - Navigate to: < https://github.com/hypercerts-org/hypercerts-lexicon/actions/workflows/release.yml >
66110 - Click "Run workflow"
67- - Select the branch (typically ` main ` )
111+ - Select the branch: ** ` main ` ** (the workflow automatically detects this is a stable release )
68112 - Click "Run workflow" to start
69113
70- 4 . ** What happens:**
114+ 3 . ** What happens:**
71115 - The workflow validates the code and regenerates TypeScript types
116+ - If ` pre.json ` exists (from ` develop ` ), verifies that prerelease mode has been exited
72117 - If there are pending changesets, it creates a "Release Pull Request"
118+ - The Release PR will remove prerelease tags (if any) and exit prerelease mode
73119 - Merge the Release PR to publish to npm with the ` latest ` tag
74120 - If no changesets exist, nothing is published
75121
76122## Publishing a Beta Release
77123
78124To publish a beta/prerelease version:
79125
80- 1 . ** Navigate to GitHub Actions:**
81- - Go to the "Actions" tab
82-
83- 2 . ** Select the workflow:**
84- - Choose "Release Beta"
85-
86- 3 . ** Run the workflow:**
126+ 1 . ** Run the workflow:**
127+ - Navigate to: < https://github.com/hypercerts-org/hypercerts-lexicon/actions/workflows/release.yml >
87128 - Click "Run workflow"
88- - Select the branch (must be ` main ` )
129+ - Select the branch: ** ` develop ` ** (the workflow automatically detects this is a beta release )
89130 - Click "Run workflow"
90131
91- 4 . ** What happens:**
92- - The workflow enters beta prerelease mode (if not already)
132+ 2 . ** What happens:**
133+ - The workflow validates the code and regenerates TypeScript types
134+ - Enters beta prerelease mode (if not already) and commits ` pre.json ` to ` develop `
93135 - Versions packages based on pending changesets
94136 - Publishes to npm with the ` beta ` tag
95137 - Version format: ` 0.9.0-beta.1 ` , ` 0.9.0-beta.2 ` , etc.
96- - Commits and pushes version changes back to the repository
138+ - Commits and pushes version changes back to the ` develop ` branch
97139
98- ** Note:** This workflow requires the ` RELEASE_PAT ` secret to bypass
99- branch protection rules when pushing version changes.
140+ ** Note:** Beta releases run on the ` develop ` branch, so no ` RELEASE_PAT ` is needed (unlike protected ` main ` branch).
100141
101142## Validating Releases (PRs)
102143
103- When you open a pull request, the "PR Check" workflow automatically
144+ When you open a pull request to ` main ` , the "PR Check" workflow automatically
104145runs to:
105146
106147- Check if package changes (lexicons, types, package.json) have
107148 corresponding changesets
108149- Warn if changesets are missing
150+ - ** Reject the PR if ` pre.json ` exists without exit intent** - This only applies
151+ when merging from ` develop ` to ` main ` . It ensures prerelease mode has been
152+ properly exited before merging. Direct work on ` main ` doesn't have ` pre.json ` ,
153+ so this check is skipped.
109154
110- This helps ensure all user-facing changes are properly documented
111- before merging .
155+ This helps ensure all user-facing changes are properly documented and that
156+ prerelease mode is correctly managed when using the ` develop ` → ` main ` flow .
112157
113158## Version Management
114159
0 commit comments