@programinglive/commiter 1.0.6 โ 1.0.8
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/CHANGELOG.md +49 -35
- package/CODE_OF_CONDUCT.md +36 -36
- package/LICENSE +21 -21
- package/PUBLISH.md +116 -116
- package/README.md +181 -181
- package/SECURITY.md +30 -30
- package/commitlint.config.cjs +4 -4
- package/index.js +148 -129
- package/package.json +94 -94
- package/scripts/release.js +97 -0
package/README.md
CHANGED
|
@@ -1,181 +1,181 @@
|
|
|
1
|
-
# Commiter ๐
|
|
2
|
-
|
|
3
|
-
A standardized commit convention and release management tool for your repository using `standard-version`.
|
|
4
|
-
|
|
5
|
-
## Features
|
|
6
|
-
|
|
7
|
-
- โ
**Enforced Commit Conventions** - Uses Conventional Commits format
|
|
8
|
-
- ๐ฏ **Automated Versioning** - Semantic versioning (major, minor, patch)
|
|
9
|
-
- ๐ **Changelog Generation** - Automatic CHANGELOG.md with icons
|
|
10
|
-
- ๐ **Git Hooks** - Pre-commit and commit-msg validation via Husky
|
|
11
|
-
- ๐จ **Icon Support** - Each commit type has a dedicated icon in releases
|
|
12
|
-
|
|
13
|
-
## Installation
|
|
14
|
-
|
|
15
|
-
Install the package globally or as a dev dependency in your project:
|
|
16
|
-
|
|
17
|
-
```bash
|
|
18
|
-
# Install globally
|
|
19
|
-
npm install -g @programinglive/commiter
|
|
20
|
-
|
|
21
|
-
# Or install as dev dependency
|
|
22
|
-
npm install --save-dev @programinglive/commiter
|
|
23
|
-
|
|
24
|
-
# Or use npx (no installation required)
|
|
25
|
-
npx @programinglive/commiter
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
After installation in your project, the Husky hooks will be automatically set up for commit message validation.
|
|
29
|
-
|
|
30
|
-
## Commit Message Format
|
|
31
|
-
|
|
32
|
-
All commits must follow the [Conventional Commits](https://www.conventionalcommits.org/) specification:
|
|
33
|
-
|
|
34
|
-
```
|
|
35
|
-
<type>(<scope>): <subject>
|
|
36
|
-
|
|
37
|
-
<body>
|
|
38
|
-
|
|
39
|
-
<footer>
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
### Commit Types with Icons
|
|
43
|
-
|
|
44
|
-
| Type | Icon | Description | Changelog Section |
|
|
45
|
-
|------|------|-------------|-------------------|
|
|
46
|
-
| `feat` | โจ | New feature | โจ Features |
|
|
47
|
-
| `fix` | ๐ | Bug fix | ๐ Bug Fixes |
|
|
48
|
-
| `perf` | โก | Performance improvement | โก Performance |
|
|
49
|
-
| `refactor` | โป๏ธ | Code refactoring | โป๏ธ Refactors |
|
|
50
|
-
| `docs` | ๐ | Documentation changes | ๐ Documentation |
|
|
51
|
-
| `style` | ๐ | Code style changes | ๐ Styles |
|
|
52
|
-
| `test` | โ
| Test additions/changes | โ
Tests |
|
|
53
|
-
| `build` | ๐๏ธ | Build system changes | ๐๏ธ Build System |
|
|
54
|
-
| `ci` | ๐ท | CI/CD changes | ๐ท Continuous Integration |
|
|
55
|
-
| `chore` | ๐งน | Maintenance tasks | ๐งน Chores |
|
|
56
|
-
| `revert` | โช | Revert previous commit | โช Reverts |
|
|
57
|
-
|
|
58
|
-
### Examples
|
|
59
|
-
|
|
60
|
-
```bash
|
|
61
|
-
# Feature
|
|
62
|
-
git commit -m "feat(auth): add JWT authentication"
|
|
63
|
-
|
|
64
|
-
# Bug fix
|
|
65
|
-
git commit -m "fix(api): resolve null pointer exception"
|
|
66
|
-
|
|
67
|
-
# Breaking change
|
|
68
|
-
git commit -m "feat(api)!: redesign user endpoint
|
|
69
|
-
|
|
70
|
-
BREAKING CHANGE: The user endpoint now returns different data structure"
|
|
71
|
-
|
|
72
|
-
# With scope and body
|
|
73
|
-
git commit -m "perf(database): optimize query performance
|
|
74
|
-
|
|
75
|
-
Reduced query time by 50% using indexed columns"
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
## Release Commands
|
|
79
|
-
|
|
80
|
-
### Patch Release (1.0.0 โ 1.0.1)
|
|
81
|
-
|
|
82
|
-
For bug fixes and minor changes:
|
|
83
|
-
|
|
84
|
-
```bash
|
|
85
|
-
npm run release:patch
|
|
86
|
-
```
|
|
87
|
-
|
|
88
|
-
### Minor Release (1.0.0 โ 1.1.0)
|
|
89
|
-
|
|
90
|
-
For new features (backwards compatible):
|
|
91
|
-
|
|
92
|
-
```bash
|
|
93
|
-
npm run release:minor
|
|
94
|
-
```
|
|
95
|
-
|
|
96
|
-
### Major Release (1.0.0 โ 2.0.0)
|
|
97
|
-
|
|
98
|
-
For breaking changes:
|
|
99
|
-
|
|
100
|
-
```bash
|
|
101
|
-
npm run release:major
|
|
102
|
-
```
|
|
103
|
-
|
|
104
|
-
### Automatic Release
|
|
105
|
-
|
|
106
|
-
Let `standard-version` determine the version bump based on commits:
|
|
107
|
-
|
|
108
|
-
```bash
|
|
109
|
-
npm run release
|
|
110
|
-
```
|
|
111
|
-
|
|
112
|
-
## What Happens During Release?
|
|
113
|
-
|
|
114
|
-
1. ๐ Analyzes commits since last release
|
|
115
|
-
2. ๐ข Bumps version in `package.json`
|
|
116
|
-
3. ๐ Updates `CHANGELOG.md` with icons
|
|
117
|
-
4. ๐ท๏ธ Creates a git tag
|
|
118
|
-
5. ๐พ Commits changes with format: `chore(release): v1.2.3 ๐`
|
|
119
|
-
|
|
120
|
-
## Push Your Release
|
|
121
|
-
|
|
122
|
-
After running a release command, push to remote:
|
|
123
|
-
|
|
124
|
-
```bash
|
|
125
|
-
git push --follow-tags origin main
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
## Pre-commit Hooks
|
|
129
|
-
|
|
130
|
-
The following hooks are automatically enforced:
|
|
131
|
-
|
|
132
|
-
- **commit-msg**: Validates commit message format using commitlint
|
|
133
|
-
- **pre-commit**: Runs tests before allowing commits
|
|
134
|
-
|
|
135
|
-
## Configuration Files
|
|
136
|
-
|
|
137
|
-
- `package.json` - Contains `standard-version` configuration
|
|
138
|
-
- `commitlint.config.js` - Commitlint rules
|
|
139
|
-
- `.husky/commit-msg` - Commit message validation hook
|
|
140
|
-
- `.husky/pre-commit` - Pre-commit test hook
|
|
141
|
-
|
|
142
|
-
## Troubleshooting
|
|
143
|
-
|
|
144
|
-
### Commit message validation fails
|
|
145
|
-
|
|
146
|
-
Ensure your commit message follows the format:
|
|
147
|
-
```
|
|
148
|
-
type(scope): subject
|
|
149
|
-
```
|
|
150
|
-
|
|
151
|
-
Valid types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`
|
|
152
|
-
|
|
153
|
-
Release commits generated by `standard-version` such as `chore(release): 1.0.0 ๐` are automatically ignored by `commitlint`.
|
|
154
|
-
|
|
155
|
-
### First release
|
|
156
|
-
|
|
157
|
-
If this is your first release and you don't have a version tag yet:
|
|
158
|
-
|
|
159
|
-
```bash
|
|
160
|
-
npm run release -- --first-release
|
|
161
|
-
```
|
|
162
|
-
|
|
163
|
-
Running the setup command ensures the default `npm test` script is `echo "No tests specified"`, preventing the Husky `pre-commit` hook from failing during this initial release. Replace it with your real test command once available.
|
|
164
|
-
|
|
165
|
-
### Dry run
|
|
166
|
-
|
|
167
|
-
To see what would happen without making changes:
|
|
168
|
-
|
|
169
|
-
```bash
|
|
170
|
-
npm run release -- --dry-run
|
|
171
|
-
```
|
|
172
|
-
|
|
173
|
-
## Contributing
|
|
174
|
-
|
|
175
|
-
Contributions are welcome! Please read [CONTRIBUTING.md](CONTRIBUTING.md) for details on our code of conduct and the process for submitting pull requests.
|
|
176
|
-
|
|
177
|
-
## License
|
|
178
|
-
|
|
179
|
-
MIT License - see the [LICENSE](LICENSE) file for details.
|
|
180
|
-
|
|
181
|
-
This project is open source and free to use, modify, and distribute at your own risk.
|
|
1
|
+
# Commiter ๐
|
|
2
|
+
|
|
3
|
+
A standardized commit convention and release management tool for your repository using `standard-version`.
|
|
4
|
+
|
|
5
|
+
## Features
|
|
6
|
+
|
|
7
|
+
- โ
**Enforced Commit Conventions** - Uses Conventional Commits format
|
|
8
|
+
- ๐ฏ **Automated Versioning** - Semantic versioning (major, minor, patch)
|
|
9
|
+
- ๐ **Changelog Generation** - Automatic CHANGELOG.md with icons
|
|
10
|
+
- ๐ **Git Hooks** - Pre-commit and commit-msg validation via Husky
|
|
11
|
+
- ๐จ **Icon Support** - Each commit type has a dedicated icon in releases
|
|
12
|
+
|
|
13
|
+
## Installation
|
|
14
|
+
|
|
15
|
+
Install the package globally or as a dev dependency in your project:
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
# Install globally
|
|
19
|
+
npm install -g @programinglive/commiter
|
|
20
|
+
|
|
21
|
+
# Or install as dev dependency
|
|
22
|
+
npm install --save-dev @programinglive/commiter
|
|
23
|
+
|
|
24
|
+
# Or use npx (no installation required)
|
|
25
|
+
npx @programinglive/commiter
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
After installation in your project, the Husky hooks will be automatically set up for commit message validation.
|
|
29
|
+
|
|
30
|
+
## Commit Message Format
|
|
31
|
+
|
|
32
|
+
All commits must follow the [Conventional Commits](https://www.conventionalcommits.org/) specification:
|
|
33
|
+
|
|
34
|
+
```
|
|
35
|
+
<type>(<scope>): <subject>
|
|
36
|
+
|
|
37
|
+
<body>
|
|
38
|
+
|
|
39
|
+
<footer>
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### Commit Types with Icons
|
|
43
|
+
|
|
44
|
+
| Type | Icon | Description | Changelog Section |
|
|
45
|
+
|------|------|-------------|-------------------|
|
|
46
|
+
| `feat` | โจ | New feature | โจ Features |
|
|
47
|
+
| `fix` | ๐ | Bug fix | ๐ Bug Fixes |
|
|
48
|
+
| `perf` | โก | Performance improvement | โก Performance |
|
|
49
|
+
| `refactor` | โป๏ธ | Code refactoring | โป๏ธ Refactors |
|
|
50
|
+
| `docs` | ๐ | Documentation changes | ๐ Documentation |
|
|
51
|
+
| `style` | ๐ | Code style changes | ๐ Styles |
|
|
52
|
+
| `test` | โ
| Test additions/changes | โ
Tests |
|
|
53
|
+
| `build` | ๐๏ธ | Build system changes | ๐๏ธ Build System |
|
|
54
|
+
| `ci` | ๐ท | CI/CD changes | ๐ท Continuous Integration |
|
|
55
|
+
| `chore` | ๐งน | Maintenance tasks | ๐งน Chores |
|
|
56
|
+
| `revert` | โช | Revert previous commit | โช Reverts |
|
|
57
|
+
|
|
58
|
+
### Examples
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
# Feature
|
|
62
|
+
git commit -m "feat(auth): add JWT authentication"
|
|
63
|
+
|
|
64
|
+
# Bug fix
|
|
65
|
+
git commit -m "fix(api): resolve null pointer exception"
|
|
66
|
+
|
|
67
|
+
# Breaking change
|
|
68
|
+
git commit -m "feat(api)!: redesign user endpoint
|
|
69
|
+
|
|
70
|
+
BREAKING CHANGE: The user endpoint now returns different data structure"
|
|
71
|
+
|
|
72
|
+
# With scope and body
|
|
73
|
+
git commit -m "perf(database): optimize query performance
|
|
74
|
+
|
|
75
|
+
Reduced query time by 50% using indexed columns"
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
## Release Commands
|
|
79
|
+
|
|
80
|
+
### Patch Release (1.0.0 โ 1.0.1)
|
|
81
|
+
|
|
82
|
+
For bug fixes and minor changes:
|
|
83
|
+
|
|
84
|
+
```bash
|
|
85
|
+
npm run release:patch
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
### Minor Release (1.0.0 โ 1.1.0)
|
|
89
|
+
|
|
90
|
+
For new features (backwards compatible):
|
|
91
|
+
|
|
92
|
+
```bash
|
|
93
|
+
npm run release:minor
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
### Major Release (1.0.0 โ 2.0.0)
|
|
97
|
+
|
|
98
|
+
For breaking changes:
|
|
99
|
+
|
|
100
|
+
```bash
|
|
101
|
+
npm run release:major
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
### Automatic Release
|
|
105
|
+
|
|
106
|
+
Let `standard-version` determine the version bump based on commits:
|
|
107
|
+
|
|
108
|
+
```bash
|
|
109
|
+
npm run release
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
## What Happens During Release?
|
|
113
|
+
|
|
114
|
+
1. ๐ Analyzes commits since last release
|
|
115
|
+
2. ๐ข Bumps version in `package.json`
|
|
116
|
+
3. ๐ Updates `CHANGELOG.md` with icons
|
|
117
|
+
4. ๐ท๏ธ Creates a git tag
|
|
118
|
+
5. ๐พ Commits changes with format: `chore(release): v1.2.3 ๐`
|
|
119
|
+
|
|
120
|
+
## Push Your Release
|
|
121
|
+
|
|
122
|
+
After running a release command, push to remote:
|
|
123
|
+
|
|
124
|
+
```bash
|
|
125
|
+
git push --follow-tags origin main
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
## Pre-commit Hooks
|
|
129
|
+
|
|
130
|
+
The following hooks are automatically enforced:
|
|
131
|
+
|
|
132
|
+
- **commit-msg**: Validates commit message format using commitlint
|
|
133
|
+
- **pre-commit**: Runs tests before allowing commits
|
|
134
|
+
|
|
135
|
+
## Configuration Files
|
|
136
|
+
|
|
137
|
+
- `package.json` - Contains `standard-version` configuration
|
|
138
|
+
- `commitlint.config.js` - Commitlint rules
|
|
139
|
+
- `.husky/commit-msg` - Commit message validation hook
|
|
140
|
+
- `.husky/pre-commit` - Pre-commit test hook
|
|
141
|
+
|
|
142
|
+
## Troubleshooting
|
|
143
|
+
|
|
144
|
+
### Commit message validation fails
|
|
145
|
+
|
|
146
|
+
Ensure your commit message follows the format:
|
|
147
|
+
```
|
|
148
|
+
type(scope): subject
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
Valid types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`
|
|
152
|
+
|
|
153
|
+
Release commits generated by `standard-version` such as `chore(release): 1.0.0 ๐` are automatically ignored by `commitlint`.
|
|
154
|
+
|
|
155
|
+
### First release
|
|
156
|
+
|
|
157
|
+
If this is your first release and you don't have a version tag yet:
|
|
158
|
+
|
|
159
|
+
```bash
|
|
160
|
+
npm run release -- --first-release
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
Running the setup command ensures the default `npm test` script is `echo "No tests specified"`, preventing the Husky `pre-commit` hook from failing during this initial release. Replace it with your real test command once available.
|
|
164
|
+
|
|
165
|
+
### Dry run
|
|
166
|
+
|
|
167
|
+
To see what would happen without making changes:
|
|
168
|
+
|
|
169
|
+
```bash
|
|
170
|
+
npm run release -- --dry-run
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
## Contributing
|
|
174
|
+
|
|
175
|
+
Contributions are welcome! Please read [CONTRIBUTING.md](CONTRIBUTING.md) for details on our code of conduct and the process for submitting pull requests.
|
|
176
|
+
|
|
177
|
+
## License
|
|
178
|
+
|
|
179
|
+
MIT License - see the [LICENSE](LICENSE) file for details.
|
|
180
|
+
|
|
181
|
+
This project is open source and free to use, modify, and distribute at your own risk.
|
package/SECURITY.md
CHANGED
|
@@ -1,30 +1,30 @@
|
|
|
1
|
-
# Security Policy
|
|
2
|
-
|
|
3
|
-
## Reporting a Vulnerability
|
|
4
|
-
|
|
5
|
-
If you discover a security vulnerability in `@programinglive/commiter`, please report it responsibly.
|
|
6
|
-
|
|
7
|
-
Send your report to: [security@programinglive.com](mailto:security@programinglive.com).
|
|
8
|
-
|
|
9
|
-
Please include:
|
|
10
|
-
- A detailed description of the vulnerability
|
|
11
|
-
- Steps to reproduce the issue
|
|
12
|
-
- Any potential impact
|
|
13
|
-
- Optional: Suggested mitigation or patch
|
|
14
|
-
|
|
15
|
-
We aim to respond within **48 hours** and will keep you informed of our progress.
|
|
16
|
-
|
|
17
|
-
## Supported Versions
|
|
18
|
-
|
|
19
|
-
We support the latest released version of the package. Please ensure you are running the most recent version before reporting issues.
|
|
20
|
-
|
|
21
|
-
## Disclosure Policy
|
|
22
|
-
|
|
23
|
-
We follow a coordinated disclosure process:
|
|
24
|
-
1. Acknowledge receipt of your report within 48 hours
|
|
25
|
-
2. Assess the vulnerability and determine severity
|
|
26
|
-
3. Fix the issue and prepare a release
|
|
27
|
-
4. Credit the reporter (if desired)
|
|
28
|
-
5. Publish a security advisory detailing the fix
|
|
29
|
-
|
|
30
|
-
Thank you for helping keep our project secure!
|
|
1
|
+
# Security Policy
|
|
2
|
+
|
|
3
|
+
## Reporting a Vulnerability
|
|
4
|
+
|
|
5
|
+
If you discover a security vulnerability in `@programinglive/commiter`, please report it responsibly.
|
|
6
|
+
|
|
7
|
+
Send your report to: [security@programinglive.com](mailto:security@programinglive.com).
|
|
8
|
+
|
|
9
|
+
Please include:
|
|
10
|
+
- A detailed description of the vulnerability
|
|
11
|
+
- Steps to reproduce the issue
|
|
12
|
+
- Any potential impact
|
|
13
|
+
- Optional: Suggested mitigation or patch
|
|
14
|
+
|
|
15
|
+
We aim to respond within **48 hours** and will keep you informed of our progress.
|
|
16
|
+
|
|
17
|
+
## Supported Versions
|
|
18
|
+
|
|
19
|
+
We support the latest released version of the package. Please ensure you are running the most recent version before reporting issues.
|
|
20
|
+
|
|
21
|
+
## Disclosure Policy
|
|
22
|
+
|
|
23
|
+
We follow a coordinated disclosure process:
|
|
24
|
+
1. Acknowledge receipt of your report within 48 hours
|
|
25
|
+
2. Assess the vulnerability and determine severity
|
|
26
|
+
3. Fix the issue and prepare a release
|
|
27
|
+
4. Credit the reporter (if desired)
|
|
28
|
+
5. Publish a security advisory detailing the fix
|
|
29
|
+
|
|
30
|
+
Thank you for helping keep our project secure!
|
package/commitlint.config.cjs
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
module.exports = {
|
|
2
|
-
extends: ['@commitlint/config-conventional'],
|
|
3
|
-
ignores: [(message) => message.startsWith('chore(release):')]
|
|
4
|
-
};
|
|
1
|
+
module.exports = {
|
|
2
|
+
extends: ['@commitlint/config-conventional'],
|
|
3
|
+
ignores: [(message) => message.startsWith('chore(release):')]
|
|
4
|
+
};
|