@programinglive/commiter 1.2.12 → 1.2.16
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.github/ISSUE_TEMPLATE/bug_report.md +28 -28
- package/.github/ISSUE_TEMPLATE/config.yml +5 -5
- package/.github/ISSUE_TEMPLATE/feature_request.md +20 -20
- package/.github/PULL_REQUEST_TEMPLATE.md +24 -24
- package/.github/workflows/publish.yml +8 -5
- package/CHANGELOG.md +263 -235
- package/CODE_OF_CONDUCT.md +36 -36
- package/LICENSE +21 -21
- package/PRD.md +96 -96
- package/PUBLISH.md +142 -142
- package/README.md +217 -217
- package/SECURITY.md +30 -30
- package/commitlint.config.cjs +4 -4
- package/docs/CREATE_RELEASES.md +103 -103
- package/docs/QUICK_RELEASE_GUIDE.md +101 -101
- package/docs/release-notes/RELEASE_NOTES.md +217 -185
- package/index.js +199 -199
- package/netlify.toml +2 -2
- package/package.json +96 -96
- package/scripts/create-releases.js +219 -219
- package/scripts/release.cjs +258 -258
- package/scripts/update-release-notes.cjs +182 -182
- package/web/README.md +79 -79
- package/web/css/style.css +963 -963
- package/web/favicon.svg +10 -10
- package/web/index.html +510 -510
- package/web/js/script.js +256 -256
- package/web/og-image.svg +24 -24
- package/.netlify/netlify.toml +0 -25
- package/.netlify/state.json +0 -3
package/PRD.md
CHANGED
|
@@ -1,96 +1,96 @@
|
|
|
1
|
-
# Commiter Product Requirements Document (PRD)
|
|
2
|
-
|
|
3
|
-
## 1. Overview
|
|
4
|
-
Commiter is a CLI utility that bootstraps and automates conventional release workflows for JavaScript/TypeScript projects. It enforces commit conventions, orchestrates semantic version bumps, keeps release tooling configured, and surfaces feedback during release execution so teams can ship confidently.
|
|
5
|
-
|
|
6
|
-
## 2. Problem Statement
|
|
7
|
-
Growing teams often struggle to keep release processes consistent: commit messages drift from convention, changelogs become stale, and release scripts accumulate manual steps. Commiter removes this friction by installing opinionated tooling, providing curated scripts, and running guard rails (tests, linters) before invoking `standard-version` to publish a release.
|
|
8
|
-
|
|
9
|
-
## 3. Goals & Success Metrics
|
|
10
|
-
- **Consistent releases**: Every release run through Commiter formats commits, updates changelogs, tags, and version bumps without manual editing.
|
|
11
|
-
- **Low ceremony onboarding**: A single `npx commiter` command prepares repositories (Husky, commitlint, release scripts).
|
|
12
|
-
- **Signal-rich automation**: Release logs clearly show which steps ran, including any warnings (e.g., tests skipped). Zero noisy deprecation warnings.
|
|
13
|
-
- **Reliability**: New releases do not regress existing behavior; the automated test suite passes (`node --test`).
|
|
14
|
-
- **Adoption Metric**: Track installations (npm downloads) and successful release script exits.
|
|
15
|
-
|
|
16
|
-
## 4. Personas
|
|
17
|
-
1. **Solo Maintainer** – wants painless semantic releases without memorizing commands.
|
|
18
|
-
2. **Team Lead** – enforces commit standards across contributors and ensures releases produce accurate changelogs.
|
|
19
|
-
3. **DevOps/CI Engineer** – integrates Commiter’s release command into CI pipelines and expects deterministic, machine-readable output.
|
|
20
|
-
|
|
21
|
-
## 5. Key Features
|
|
22
|
-
- **Setup CLI (`index.js`)**
|
|
23
|
-
- Installs dev dependencies (`standard-version`, `commitlint`, `husky`).
|
|
24
|
-
- Configures package scripts (`npm run release`, `release:major/minor/patch`, `release:first`).
|
|
25
|
-
- Creates Husky hooks and commitlint configuration.
|
|
26
|
-
- Generates release helper script and ensures executable permissions (POSIX-friendly).
|
|
27
|
-
- **Release Helper (`scripts/release.js`)**
|
|
28
|
-
- Detects release type from CLI args or npm context.
|
|
29
|
-
- Runs project tests via detected package manager before releasing.
|
|
30
|
-
- Invokes `standard-version`, passing the preload script via `NODE_OPTIONS`.
|
|
31
|
-
- Supports first release mode that sets version to 0.0.1 for new projects.
|
|
32
|
-
- Stays focused on repository assets only (website updates are intentionally manual to avoid cross-project impacts).
|
|
33
|
-
- **Preload Patching (`scripts/preload/fs-f-ok.cjs`)**
|
|
34
|
-
- Hooks Node’s module loader to transparently replace deprecated `fs.F_OK` usages in `standard-version` without altering `node_modules`.
|
|
35
|
-
- **Website & Documentation**
|
|
36
|
-
- Professional landing page in `web/` directory.
|
|
37
|
-
- Automated GitHub Releases generation.
|
|
38
|
-
- Open Graph social media preview support.
|
|
39
|
-
- **Testing**
|
|
40
|
-
- Suite executed via `node --test` covers setup utilities, release argument parsing, and the preload patch.
|
|
41
|
-
|
|
42
|
-
## 6. Functional Requirements
|
|
43
|
-
1. Running `npx @programinglive/commiter` inside a Node project should configure release tooling without manual edits.
|
|
44
|
-
2. `npm run release` must:
|
|
45
|
-
- Run the project’s tests (if defined) with the correct package manager.
|
|
46
|
-
- Execute `standard-version`, passing the preload script via `NODE_OPTIONS`.
|
|
47
|
-
- Exit with non-zero status if tests or standard-version commands fail.
|
|
48
|
-
3. CLI should provide friendly console output (status icons, instructions).
|
|
49
|
-
4. The preload script must eliminate `[DEP0176] fs.F_OK` warnings on supported Node versions.
|
|
50
|
-
5. Documentation (README, PRD, release notes) remains shipped with the package.
|
|
51
|
-
|
|
52
|
-
## 7. Non-Functional Requirements
|
|
53
|
-
- **Compatibility**: Supports Node.js 18+ (aligning with dependencies); tested on Windows/macOS/Linux.
|
|
54
|
-
- **Maintainability**: Avoid direct edits to dependencies; wrap behavior in Commiter-controlled modules.
|
|
55
|
-
- **Performance**: Release command overhead minimal (<1s additional startup time) beyond running tests and standard-version.
|
|
56
|
-
- **Security**: No network requests during CLI execution beyond npm installs triggered by the user.
|
|
57
|
-
|
|
58
|
-
## 8. User Journeys
|
|
59
|
-
1. **Initial Setup**
|
|
60
|
-
- Run `npx @programinglive/commiter`.
|
|
61
|
-
- Tool installs dependencies, updates `package.json`, and scaffolds Husky hooks.
|
|
62
|
-
- Maintainer confirms success message and new scripts.
|
|
63
|
-
2. **First Release**
|
|
64
|
-
- Developer runs `npm run release:first` for new projects.
|
|
65
|
-
- Commiter sets version to 0.0.1, runs tests, creates initial changelog and git tag.
|
|
66
|
-
- Project foundation established with proper semantic versioning.
|
|
67
|
-
3. **Standard Release**
|
|
68
|
-
- Developer runs `npm run release minor` or `npm run release` (defaults to patch).
|
|
69
|
-
- Commiter runs tests, ensures preload patch prevents deprecation warnings, executes `standard-version`.
|
|
70
|
-
- Release completes with updated changelog and git tag.
|
|
71
|
-
4. **CI Pipeline**
|
|
72
|
-
- CI job executes `npm run release -- --prerelease beta`.
|
|
73
|
-
- Logs show tests executed, no deprecation warnings, and release artifacts generated.
|
|
74
|
-
|
|
75
|
-
## 9. Milestones & Roadmap
|
|
76
|
-
- **v1.1.x** (current)
|
|
77
|
-
- Deprecation warning mitigation, enhanced tests, PRD + release documentation.
|
|
78
|
-
- **Future Considerations**
|
|
79
|
-
- Support for monorepo detection (Lerna/Nx) to run scoped releases.
|
|
80
|
-
- Optional lint/test command customization via config file.
|
|
81
|
-
- Telemetry opt-in for release statistics (downloads, success rates).
|
|
82
|
-
|
|
83
|
-
## 10. Risks & Mitigations
|
|
84
|
-
- **Dependency API Changes**: Upstream packages may alter file paths. Mitigate with targeted module resolution and tests.
|
|
85
|
-
- **User Customization Conflicts**: Custom scripts might skip tests. Provide documentation for overriding behavior.
|
|
86
|
-
- **Platform Differences**: Windows path quoting; addressed via `buildPreloadFlag` helper.
|
|
87
|
-
|
|
88
|
-
## 11. Release & QA Checklist
|
|
89
|
-
- [x] `npm test` (alias for `node --test`) passes.
|
|
90
|
-
- [x] Manual run of `node scripts/release.js --help` shows no `[DEP0176]` warning.
|
|
91
|
-
- [ ] Update `CHANGELOG.md` (handled by standard-version during actual release).
|
|
92
|
-
- [ ] Verify README reflects latest setup instructions before shipping.
|
|
93
|
-
|
|
94
|
-
## 12. Appendices
|
|
95
|
-
- **Release Notes**: See `docs/release-notes/` for per-change summaries.
|
|
96
|
-
- **Testing Artifacts**: `test/` directory contains Node test runner suites.
|
|
1
|
+
# Commiter Product Requirements Document (PRD)
|
|
2
|
+
|
|
3
|
+
## 1. Overview
|
|
4
|
+
Commiter is a CLI utility that bootstraps and automates conventional release workflows for JavaScript/TypeScript projects. It enforces commit conventions, orchestrates semantic version bumps, keeps release tooling configured, and surfaces feedback during release execution so teams can ship confidently.
|
|
5
|
+
|
|
6
|
+
## 2. Problem Statement
|
|
7
|
+
Growing teams often struggle to keep release processes consistent: commit messages drift from convention, changelogs become stale, and release scripts accumulate manual steps. Commiter removes this friction by installing opinionated tooling, providing curated scripts, and running guard rails (tests, linters) before invoking `standard-version` to publish a release.
|
|
8
|
+
|
|
9
|
+
## 3. Goals & Success Metrics
|
|
10
|
+
- **Consistent releases**: Every release run through Commiter formats commits, updates changelogs, tags, and version bumps without manual editing.
|
|
11
|
+
- **Low ceremony onboarding**: A single `npx commiter` command prepares repositories (Husky, commitlint, release scripts).
|
|
12
|
+
- **Signal-rich automation**: Release logs clearly show which steps ran, including any warnings (e.g., tests skipped). Zero noisy deprecation warnings.
|
|
13
|
+
- **Reliability**: New releases do not regress existing behavior; the automated test suite passes (`node --test`).
|
|
14
|
+
- **Adoption Metric**: Track installations (npm downloads) and successful release script exits.
|
|
15
|
+
|
|
16
|
+
## 4. Personas
|
|
17
|
+
1. **Solo Maintainer** – wants painless semantic releases without memorizing commands.
|
|
18
|
+
2. **Team Lead** – enforces commit standards across contributors and ensures releases produce accurate changelogs.
|
|
19
|
+
3. **DevOps/CI Engineer** – integrates Commiter’s release command into CI pipelines and expects deterministic, machine-readable output.
|
|
20
|
+
|
|
21
|
+
## 5. Key Features
|
|
22
|
+
- **Setup CLI (`index.js`)**
|
|
23
|
+
- Installs dev dependencies (`standard-version`, `commitlint`, `husky`).
|
|
24
|
+
- Configures package scripts (`npm run release`, `release:major/minor/patch`, `release:first`).
|
|
25
|
+
- Creates Husky hooks and commitlint configuration.
|
|
26
|
+
- Generates release helper script and ensures executable permissions (POSIX-friendly).
|
|
27
|
+
- **Release Helper (`scripts/release.js`)**
|
|
28
|
+
- Detects release type from CLI args or npm context.
|
|
29
|
+
- Runs project tests via detected package manager before releasing.
|
|
30
|
+
- Invokes `standard-version`, passing the preload script via `NODE_OPTIONS`.
|
|
31
|
+
- Supports first release mode that sets version to 0.0.1 for new projects.
|
|
32
|
+
- Stays focused on repository assets only (website updates are intentionally manual to avoid cross-project impacts).
|
|
33
|
+
- **Preload Patching (`scripts/preload/fs-f-ok.cjs`)**
|
|
34
|
+
- Hooks Node’s module loader to transparently replace deprecated `fs.F_OK` usages in `standard-version` without altering `node_modules`.
|
|
35
|
+
- **Website & Documentation**
|
|
36
|
+
- Professional landing page in `web/` directory.
|
|
37
|
+
- Automated GitHub Releases generation.
|
|
38
|
+
- Open Graph social media preview support.
|
|
39
|
+
- **Testing**
|
|
40
|
+
- Suite executed via `node --test` covers setup utilities, release argument parsing, and the preload patch.
|
|
41
|
+
|
|
42
|
+
## 6. Functional Requirements
|
|
43
|
+
1. Running `npx @programinglive/commiter` inside a Node project should configure release tooling without manual edits.
|
|
44
|
+
2. `npm run release` must:
|
|
45
|
+
- Run the project’s tests (if defined) with the correct package manager.
|
|
46
|
+
- Execute `standard-version`, passing the preload script via `NODE_OPTIONS`.
|
|
47
|
+
- Exit with non-zero status if tests or standard-version commands fail.
|
|
48
|
+
3. CLI should provide friendly console output (status icons, instructions).
|
|
49
|
+
4. The preload script must eliminate `[DEP0176] fs.F_OK` warnings on supported Node versions.
|
|
50
|
+
5. Documentation (README, PRD, release notes) remains shipped with the package.
|
|
51
|
+
|
|
52
|
+
## 7. Non-Functional Requirements
|
|
53
|
+
- **Compatibility**: Supports Node.js 18+ (aligning with dependencies); tested on Windows/macOS/Linux.
|
|
54
|
+
- **Maintainability**: Avoid direct edits to dependencies; wrap behavior in Commiter-controlled modules.
|
|
55
|
+
- **Performance**: Release command overhead minimal (<1s additional startup time) beyond running tests and standard-version.
|
|
56
|
+
- **Security**: No network requests during CLI execution beyond npm installs triggered by the user.
|
|
57
|
+
|
|
58
|
+
## 8. User Journeys
|
|
59
|
+
1. **Initial Setup**
|
|
60
|
+
- Run `npx @programinglive/commiter`.
|
|
61
|
+
- Tool installs dependencies, updates `package.json`, and scaffolds Husky hooks.
|
|
62
|
+
- Maintainer confirms success message and new scripts.
|
|
63
|
+
2. **First Release**
|
|
64
|
+
- Developer runs `npm run release:first` for new projects.
|
|
65
|
+
- Commiter sets version to 0.0.1, runs tests, creates initial changelog and git tag.
|
|
66
|
+
- Project foundation established with proper semantic versioning.
|
|
67
|
+
3. **Standard Release**
|
|
68
|
+
- Developer runs `npm run release minor` or `npm run release` (defaults to patch).
|
|
69
|
+
- Commiter runs tests, ensures preload patch prevents deprecation warnings, executes `standard-version`.
|
|
70
|
+
- Release completes with updated changelog and git tag.
|
|
71
|
+
4. **CI Pipeline**
|
|
72
|
+
- CI job executes `npm run release -- --prerelease beta`.
|
|
73
|
+
- Logs show tests executed, no deprecation warnings, and release artifacts generated.
|
|
74
|
+
|
|
75
|
+
## 9. Milestones & Roadmap
|
|
76
|
+
- **v1.1.x** (current)
|
|
77
|
+
- Deprecation warning mitigation, enhanced tests, PRD + release documentation.
|
|
78
|
+
- **Future Considerations**
|
|
79
|
+
- Support for monorepo detection (Lerna/Nx) to run scoped releases.
|
|
80
|
+
- Optional lint/test command customization via config file.
|
|
81
|
+
- Telemetry opt-in for release statistics (downloads, success rates).
|
|
82
|
+
|
|
83
|
+
## 10. Risks & Mitigations
|
|
84
|
+
- **Dependency API Changes**: Upstream packages may alter file paths. Mitigate with targeted module resolution and tests.
|
|
85
|
+
- **User Customization Conflicts**: Custom scripts might skip tests. Provide documentation for overriding behavior.
|
|
86
|
+
- **Platform Differences**: Windows path quoting; addressed via `buildPreloadFlag` helper.
|
|
87
|
+
|
|
88
|
+
## 11. Release & QA Checklist
|
|
89
|
+
- [x] `npm test` (alias for `node --test`) passes.
|
|
90
|
+
- [x] Manual run of `node scripts/release.js --help` shows no `[DEP0176]` warning.
|
|
91
|
+
- [ ] Update `CHANGELOG.md` (handled by standard-version during actual release).
|
|
92
|
+
- [ ] Verify README reflects latest setup instructions before shipping.
|
|
93
|
+
|
|
94
|
+
## 12. Appendices
|
|
95
|
+
- **Release Notes**: See `docs/release-notes/` for per-change summaries.
|
|
96
|
+
- **Testing Artifacts**: `test/` directory contains Node test runner suites.
|
package/PUBLISH.md
CHANGED
|
@@ -1,142 +1,142 @@
|
|
|
1
|
-
# Publishing to NPM
|
|
2
|
-
|
|
3
|
-
This guide explains how to publish the `@programinglive/commiter` package to npm.
|
|
4
|
-
|
|
5
|
-
## Prerequisites
|
|
6
|
-
|
|
7
|
-
1. **NPM Account**: Create an account at [npmjs.com](https://www.npmjs.com/)
|
|
8
|
-
2. **Login to NPM**: Run `npm login` in your terminal
|
|
9
|
-
3. **Organization Access**: Ensure you have access to the `@programinglive` organization on npm
|
|
10
|
-
|
|
11
|
-
## Publishing Steps
|
|
12
|
-
|
|
13
|
-
### 1. Login to NPM
|
|
14
|
-
|
|
15
|
-
```bash
|
|
16
|
-
npm login
|
|
17
|
-
```
|
|
18
|
-
|
|
19
|
-
Enter your npm credentials when prompted.
|
|
20
|
-
|
|
21
|
-
### 2. Verify Package Configuration
|
|
22
|
-
|
|
23
|
-
Check that `package.json` is correctly configured:
|
|
24
|
-
|
|
25
|
-
```bash
|
|
26
|
-
npm pack --dry-run
|
|
27
|
-
```
|
|
28
|
-
|
|
29
|
-
This shows what files will be included in the package.
|
|
30
|
-
|
|
31
|
-
### 3. Publish the Package
|
|
32
|
-
|
|
33
|
-
For the first publish:
|
|
34
|
-
|
|
35
|
-
```bash
|
|
36
|
-
npm publish --access public
|
|
37
|
-
```
|
|
38
|
-
|
|
39
|
-
**Note**: The `--access public` flag is required for scoped packages (@programinglive/commiter) to be publicly accessible.
|
|
40
|
-
|
|
41
|
-
### 4. Verify Publication
|
|
42
|
-
|
|
43
|
-
Check your package on npm:
|
|
44
|
-
```
|
|
45
|
-
https://www.npmjs.com/package/@programinglive/commiter
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
## Releasing New Versions
|
|
49
|
-
|
|
50
|
-
After the initial publish, use the built-in release commands:
|
|
51
|
-
|
|
52
|
-
### Patch Release (1.0.0 → 1.0.1)
|
|
53
|
-
```bash
|
|
54
|
-
npm run release:patch
|
|
55
|
-
git push --follow-tags origin main
|
|
56
|
-
npm publish
|
|
57
|
-
```
|
|
58
|
-
|
|
59
|
-
### Minor Release (1.0.0 → 1.1.0)
|
|
60
|
-
```bash
|
|
61
|
-
npm run release:minor
|
|
62
|
-
git push --follow-tags origin main
|
|
63
|
-
npm publish
|
|
64
|
-
```
|
|
65
|
-
|
|
66
|
-
### Major Release (1.0.0 → 2.0.0)
|
|
67
|
-
```bash
|
|
68
|
-
npm run release:major
|
|
69
|
-
git push --follow-tags origin main
|
|
70
|
-
npm publish
|
|
71
|
-
```
|
|
72
|
-
|
|
73
|
-
## Automated Release Workflow
|
|
74
|
-
|
|
75
|
-
### Option 1: Manual Publishing (Traditional)
|
|
76
|
-
1. Make changes and commit using conventional commits
|
|
77
|
-
2. Run the appropriate release command
|
|
78
|
-
3. Push to GitHub with tags
|
|
79
|
-
4. Publish to npm
|
|
80
|
-
|
|
81
|
-
Example:
|
|
82
|
-
```bash
|
|
83
|
-
# Make changes
|
|
84
|
-
git add .
|
|
85
|
-
git commit -m "feat(cli): add interactive setup wizard"
|
|
86
|
-
|
|
87
|
-
# Create release
|
|
88
|
-
npm run release:minor
|
|
89
|
-
|
|
90
|
-
# Push to GitHub
|
|
91
|
-
git push --follow-tags origin main
|
|
92
|
-
|
|
93
|
-
# Publish to npm
|
|
94
|
-
npm publish
|
|
95
|
-
```
|
|
96
|
-
|
|
97
|
-
### Option 2: Automated Publishing (Recommended)
|
|
98
|
-
1. Make changes and commit using conventional commits
|
|
99
|
-
2. Run the appropriate release command
|
|
100
|
-
3. Push to GitHub with tags - **npm publishing happens automatically**
|
|
101
|
-
|
|
102
|
-
Example:
|
|
103
|
-
```bash
|
|
104
|
-
# Make changes
|
|
105
|
-
git add .
|
|
106
|
-
git commit -m "feat(cli): add interactive setup wizard"
|
|
107
|
-
|
|
108
|
-
# Create release
|
|
109
|
-
npm run release:minor
|
|
110
|
-
|
|
111
|
-
# Push to GitHub (triggers automatic npm publish)
|
|
112
|
-
git push --follow-tags origin main
|
|
113
|
-
```
|
|
114
|
-
|
|
115
|
-
**Setup Required for Automated Publishing:**
|
|
116
|
-
1. Add `NPM_TOKEN` secret to your GitHub repository
|
|
117
|
-
2. The GitHub Actions workflow (`.github/workflows/publish.yml`) will automatically:
|
|
118
|
-
- Run tests
|
|
119
|
-
- Publish to npm when a tag starting with `v` is pushed
|
|
120
|
-
- Use the `--access public` flag for scoped packages
|
|
121
|
-
|
|
122
|
-
## Unpublishing (Emergency Only)
|
|
123
|
-
|
|
124
|
-
If you need to unpublish a version within 72 hours:
|
|
125
|
-
|
|
126
|
-
```bash
|
|
127
|
-
npm unpublish @programinglive/commiter@1.0.0
|
|
128
|
-
```
|
|
129
|
-
|
|
130
|
-
**Warning**: Unpublishing is permanent and should only be used in emergencies.
|
|
131
|
-
|
|
132
|
-
## Package Visibility
|
|
133
|
-
|
|
134
|
-
- **Public**: Anyone can install and use the package
|
|
135
|
-
- **Open Source**: MIT licensed - users can modify and distribute
|
|
136
|
-
- **Free**: No cost to install or use
|
|
137
|
-
|
|
138
|
-
## Support
|
|
139
|
-
|
|
140
|
-
For issues or questions:
|
|
141
|
-
- GitHub Issues: https://github.com/programinglive/commiter/issues
|
|
142
|
-
- NPM Package: https://www.npmjs.com/package/@programinglive/commiter
|
|
1
|
+
# Publishing to NPM
|
|
2
|
+
|
|
3
|
+
This guide explains how to publish the `@programinglive/commiter` package to npm.
|
|
4
|
+
|
|
5
|
+
## Prerequisites
|
|
6
|
+
|
|
7
|
+
1. **NPM Account**: Create an account at [npmjs.com](https://www.npmjs.com/)
|
|
8
|
+
2. **Login to NPM**: Run `npm login` in your terminal
|
|
9
|
+
3. **Organization Access**: Ensure you have access to the `@programinglive` organization on npm
|
|
10
|
+
|
|
11
|
+
## Publishing Steps
|
|
12
|
+
|
|
13
|
+
### 1. Login to NPM
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
npm login
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
Enter your npm credentials when prompted.
|
|
20
|
+
|
|
21
|
+
### 2. Verify Package Configuration
|
|
22
|
+
|
|
23
|
+
Check that `package.json` is correctly configured:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
npm pack --dry-run
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
This shows what files will be included in the package.
|
|
30
|
+
|
|
31
|
+
### 3. Publish the Package
|
|
32
|
+
|
|
33
|
+
For the first publish:
|
|
34
|
+
|
|
35
|
+
```bash
|
|
36
|
+
npm publish --access public
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
**Note**: The `--access public` flag is required for scoped packages (@programinglive/commiter) to be publicly accessible.
|
|
40
|
+
|
|
41
|
+
### 4. Verify Publication
|
|
42
|
+
|
|
43
|
+
Check your package on npm:
|
|
44
|
+
```
|
|
45
|
+
https://www.npmjs.com/package/@programinglive/commiter
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
## Releasing New Versions
|
|
49
|
+
|
|
50
|
+
After the initial publish, use the built-in release commands:
|
|
51
|
+
|
|
52
|
+
### Patch Release (1.0.0 → 1.0.1)
|
|
53
|
+
```bash
|
|
54
|
+
npm run release:patch
|
|
55
|
+
git push --follow-tags origin main
|
|
56
|
+
npm publish
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
### Minor Release (1.0.0 → 1.1.0)
|
|
60
|
+
```bash
|
|
61
|
+
npm run release:minor
|
|
62
|
+
git push --follow-tags origin main
|
|
63
|
+
npm publish
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
### Major Release (1.0.0 → 2.0.0)
|
|
67
|
+
```bash
|
|
68
|
+
npm run release:major
|
|
69
|
+
git push --follow-tags origin main
|
|
70
|
+
npm publish
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
## Automated Release Workflow
|
|
74
|
+
|
|
75
|
+
### Option 1: Manual Publishing (Traditional)
|
|
76
|
+
1. Make changes and commit using conventional commits
|
|
77
|
+
2. Run the appropriate release command
|
|
78
|
+
3. Push to GitHub with tags
|
|
79
|
+
4. Publish to npm
|
|
80
|
+
|
|
81
|
+
Example:
|
|
82
|
+
```bash
|
|
83
|
+
# Make changes
|
|
84
|
+
git add .
|
|
85
|
+
git commit -m "feat(cli): add interactive setup wizard"
|
|
86
|
+
|
|
87
|
+
# Create release
|
|
88
|
+
npm run release:minor
|
|
89
|
+
|
|
90
|
+
# Push to GitHub
|
|
91
|
+
git push --follow-tags origin main
|
|
92
|
+
|
|
93
|
+
# Publish to npm
|
|
94
|
+
npm publish
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### Option 2: Automated Publishing (Recommended)
|
|
98
|
+
1. Make changes and commit using conventional commits
|
|
99
|
+
2. Run the appropriate release command
|
|
100
|
+
3. Push to GitHub with tags - **npm publishing happens automatically**
|
|
101
|
+
|
|
102
|
+
Example:
|
|
103
|
+
```bash
|
|
104
|
+
# Make changes
|
|
105
|
+
git add .
|
|
106
|
+
git commit -m "feat(cli): add interactive setup wizard"
|
|
107
|
+
|
|
108
|
+
# Create release
|
|
109
|
+
npm run release:minor
|
|
110
|
+
|
|
111
|
+
# Push to GitHub (triggers automatic npm publish)
|
|
112
|
+
git push --follow-tags origin main
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
**Setup Required for Automated Publishing:**
|
|
116
|
+
1. Add `NPM_TOKEN` secret to your GitHub repository
|
|
117
|
+
2. The GitHub Actions workflow (`.github/workflows/publish.yml`) will automatically:
|
|
118
|
+
- Run tests
|
|
119
|
+
- Publish to npm when a tag starting with `v` is pushed
|
|
120
|
+
- Use the `--access public` flag for scoped packages
|
|
121
|
+
|
|
122
|
+
## Unpublishing (Emergency Only)
|
|
123
|
+
|
|
124
|
+
If you need to unpublish a version within 72 hours:
|
|
125
|
+
|
|
126
|
+
```bash
|
|
127
|
+
npm unpublish @programinglive/commiter@1.0.0
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
**Warning**: Unpublishing is permanent and should only be used in emergencies.
|
|
131
|
+
|
|
132
|
+
## Package Visibility
|
|
133
|
+
|
|
134
|
+
- **Public**: Anyone can install and use the package
|
|
135
|
+
- **Open Source**: MIT licensed - users can modify and distribute
|
|
136
|
+
- **Free**: No cost to install or use
|
|
137
|
+
|
|
138
|
+
## Support
|
|
139
|
+
|
|
140
|
+
For issues or questions:
|
|
141
|
+
- GitHub Issues: https://github.com/programinglive/commiter/issues
|
|
142
|
+
- NPM Package: https://www.npmjs.com/package/@programinglive/commiter
|