@@ -8,20 +8,6 @@ about**, with minimal tooling and clear sources of truth.
88
99---
1010
11- ## Overview
12-
13- - Use ` npm run release:{patch,minor,major} ` to create a release branch.
14- - Push that branch and open a PR to main.
15- - Merging that branch triggers workflows that create a tag and publish the
16- release.
17- - The auto-tag workflow creates the new tag.
18- - The release workflow sees the new tag and publishes the npm and GitHub
19- releases.
20-
21- No release bots, changelog generators, or additional CLIs are required.
22-
23- ---
24-
2511## Versioning
2612
2713This project follows ** Semantic Versioning (SemVer)** :
@@ -31,9 +17,6 @@ This project follows **Semantic Versioning (SemVer)**:
3117- ** Major** (` x.0.0 ` ) — breaking changes (rule behavior changes, removals,
3218 stricter defaults)
3319
34- Versions can be updated manually in package.json or using npm’s built-in
35- tooling.
36-
3720---
3821
3922## Creating a Release
@@ -58,43 +41,35 @@ This script will:
5841
5942Then create a Pull Request to merge the release branch into main.
6043
61- Once the PR is merged, ** the tag is created automatically** .
44+ Once the PR is merged, the ` release ` workflow will run since the PR makes
45+ changes to package.json. This workflow will run the tests (again), and if the
46+ tests pass will then attempt to create a tag for the new version. If that
47+ succeeds, it then creates a release in both npm and GitHub.
6248
63- The ` auto-tag ` workflow monitors package.json changes on main and automatically
64- creates the corresponding git tag if it doesn't exist .
49+ The release branch can be deleted after the PR is merged and the releases are
50+ published .
6551
66- When the tag is created on main, this triggers the ` release ` workflow, which
67- will create the release in npm and in GitHub.
52+ No release bots, changelog generators, or additional CLIs are required.
6853
6954---
7055
7156## Automation (GitHub Actions)
7257
73- ### Automatic Tagging
74-
75- The ` auto-tag ` workflow monitors package.json changes on the main branch. When
76- a version change is detected, it automatically:
58+ ### Release Workflow
7759
78- 1 . Reads the version from package.json
79- 2 . Checks if a tag for that version already exists
80- 3 . Creates and pushes the tag if it doesn't exist
60+ The ` release ` workflow is triggered by a push to 'main' (e.g. a PR merge) that
61+ modifies "package json'. When triggered, it
8162
82- This eliminates the manual tagging step after PR merge.
83-
84- ### Publishing and Releases
85-
86- The ` release ` workflow listens for pushed tags matching ` v* ` on the main
87- branch.
88-
89- On tag push, it will:
90-
91- 1 . Check out the repository
92- 2 . Install dependencies
93- 3 . Run tests
63+ 1 . Check if a tag already exists for this version. If so, the workflow
64+ terminates.
65+ 2 . Install dependencies and run the tests. These should never fail since PRs
66+ targeting main must pass CI, but this is an extra precaution.
67+ 3 . Create and push a git tag matching the version in package.json
94684 . Publish the package to npm
95- 5 . Create a GitHub Release for the tag
69+ 5 . Create a GitHub Release with auto-generated notes
9670
97- The GitHub Release is only created if npm publishing succeeds.
71+ This single workflow handles the entire release process and ensures the npm and
72+ GitHub releases are in sync and use the version from package.json
9873
9974---
10075
@@ -116,18 +91,6 @@ Publishing requires:
11691- An npm automation token stored as a GitHub secret named ` NPM_TOKEN `
11792- ` publishConfig.access ` set appropriately in ` package.json `
11893
119- Example:
120-
121- ``` json
122- {
123- "publishConfig" : {
124- "access" : " public"
125- }
126- }
127- ```
128-
129- ---
130-
13194## Optional: Changelog
13295
13396A manual ` CHANGELOG.md ` may be maintained if desired.
0 commit comments