|
| 1 | +# Publishing Guide for Maintainers |
| 2 | + |
| 3 | +This document describes how to publish the `@hypercerts-org/lexicon` |
| 4 | +package to npm using GitHub Actions workflows. All publishing |
| 5 | +workflows are manually triggered to give you full control over when |
| 6 | +releases are made. |
| 7 | + |
| 8 | +## Prerequisites |
| 9 | + |
| 10 | +Before publishing, ensure you have: |
| 11 | + |
| 12 | +1. **GitHub Secrets configured:** |
| 13 | + - `GH_PA_TOKEN`: GitHub Personal Access Token with permissions for |
| 14 | + releases |
| 15 | + - `NPM_TOKEN`: npm access token with publish permissions for |
| 16 | + `@hypercerts-org` scope |
| 17 | + |
| 18 | +2. **GitHub Environments configured:** |
| 19 | + - `test`: For the build-and-test job |
| 20 | + - `staging`: For the semantic-release job |
| 21 | + |
| 22 | +## Publishing a Release |
| 23 | + |
| 24 | +To publish a new release to npm: |
| 25 | + |
| 26 | +1. **Navigate to GitHub Actions:** |
| 27 | + - Go to the repository on GitHub |
| 28 | + - Click on the "Actions" tab |
| 29 | + |
| 30 | +2. **Select the workflow:** |
| 31 | + - Choose "Build and release" from the workflow list |
| 32 | + |
| 33 | +3. **Run the workflow:** |
| 34 | + - Click "Run workflow" |
| 35 | + - Select the branch (typically `main`) |
| 36 | + - Click "Run workflow" to start |
| 37 | + |
| 38 | +4. **What happens:** |
| 39 | + - The workflow runs linting and regenerates TypeScript types |
| 40 | + - If successful, semantic-release analyzes your commits |
| 41 | + - If there are version-worthy changes, it: |
| 42 | + - Determines the new version based on |
| 43 | + [Conventional Commits](https://www.conventionalcommits.org/) |
| 44 | + - Updates `CHANGELOG.md` |
| 45 | + - Creates a GitHub release |
| 46 | + - Publishes to npm with the new version |
| 47 | + |
| 48 | +## Publishing a Prerelease |
| 49 | + |
| 50 | +To publish a beta/prerelease version: |
| 51 | + |
| 52 | +1. **Navigate to GitHub Actions:** |
| 53 | + - Go to the "Actions" tab |
| 54 | + |
| 55 | +2. **Select the prerelease workflow:** |
| 56 | + - Choose "Build and release - staging" |
| 57 | + |
| 58 | +3. **Run the workflow:** |
| 59 | + - Click "Run workflow" |
| 60 | + - Select the branch (typically `develop` or a feature branch) |
| 61 | + - Click "Run workflow" |
| 62 | + |
| 63 | +4. **What happens:** |
| 64 | + - Same process as above, but publishes with a `beta` tag |
| 65 | + - Version format: `1.2.3-beta.1`, `1.2.3-beta.2`, etc. |
| 66 | + |
| 67 | +## Validating Releases (PRs) |
| 68 | + |
| 69 | +When you open a pull request, the "Build and release - staging" |
| 70 | +workflow automatically runs in dry-run mode to: |
| 71 | + |
| 72 | +- Validate that the code builds successfully |
| 73 | +- Check that types regenerate correctly |
| 74 | +- Show what version would be released (without actually publishing) |
| 75 | + |
| 76 | +This helps catch issues before merging. |
| 77 | + |
| 78 | +## Version Management |
| 79 | + |
| 80 | +Versions are automatically determined by semantic-release based on |
| 81 | +commit messages: |
| 82 | + |
| 83 | +- `feat:` → minor version bump (1.0.0 → 1.1.0) |
| 84 | +- `fix:` → patch version bump (1.0.0 → 1.0.1) |
| 85 | +- `BREAKING CHANGE:` or `!` → major version bump (1.0.0 → 2.0.0) |
| 86 | + |
| 87 | +The `prepublishOnly` script ensures types are regenerated before |
| 88 | +publishing, so the published package always includes the latest |
| 89 | +generated TypeScript types. |
0 commit comments