@jmlweb/commitlint-config 2.0.1 → 2.0.2
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/CHANGELOG.md +6 -0
- package/README.md +32 -6
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
package/README.md
CHANGED
|
@@ -17,12 +17,6 @@
|
|
|
17
17
|
|
|
18
18
|
## 📦 Installation
|
|
19
19
|
|
|
20
|
-
```bash
|
|
21
|
-
npm install --save-dev @jmlweb/commitlint-config @commitlint/cli @commitlint/config-conventional
|
|
22
|
-
```
|
|
23
|
-
|
|
24
|
-
Or with pnpm:
|
|
25
|
-
|
|
26
20
|
```bash
|
|
27
21
|
pnpm add -D @jmlweb/commitlint-config @commitlint/cli @commitlint/config-conventional
|
|
28
22
|
```
|
|
@@ -96,6 +90,38 @@ export default createCommitlintConfig({
|
|
|
96
90
|
});
|
|
97
91
|
```
|
|
98
92
|
|
|
93
|
+
## 🤔 Why Use This?
|
|
94
|
+
|
|
95
|
+
> **Philosophy**: Structured commit messages enable automation, improve collaboration, and make project history meaningful and navigable.
|
|
96
|
+
|
|
97
|
+
This package enforces Conventional Commits to standardize commit messages across teams. Structured commits aren't just about consistency - they enable automated versioning, changelog generation, and make your git history actually useful for understanding project evolution.
|
|
98
|
+
|
|
99
|
+
### Design Decisions
|
|
100
|
+
|
|
101
|
+
**Conventional Commits Format**: Structured commit messages with types
|
|
102
|
+
|
|
103
|
+
- **Why**: The Conventional Commits specification enables powerful automation like semantic-release (automatic versioning), automatic changelog generation, and better git history navigation. It forces developers to think about what their change actually does (feat vs fix vs refactor), which improves code review quality
|
|
104
|
+
- **Trade-off**: Slightly more overhead when committing - must categorize changes. But the automation benefits and improved history are worth it
|
|
105
|
+
- **When to override**: For personal projects where automation isn't needed. But even solo developers benefit from clear commit history
|
|
106
|
+
|
|
107
|
+
**No Scope Restrictions by Default**: Works for any project structure
|
|
108
|
+
|
|
109
|
+
- **Why**: Different projects have different scopes (monorepo packages, feature areas, components). Not enforcing scopes makes this config flexible and zero-configuration for most projects. Teams can add scope restrictions when needed
|
|
110
|
+
- **Trade-off**: No validation that scopes make sense for your project. But this prevents the config from being opinionated about project structure
|
|
111
|
+
- **When to override**: For monorepos or large projects, define allowed scopes to ensure consistency (e.g., `['api', 'ui', 'docs']`)
|
|
112
|
+
|
|
113
|
+
**100 Character Header Limit**: Readable in all tools
|
|
114
|
+
|
|
115
|
+
- **Why**: 100 characters fits comfortably in GitHub's UI, terminal output, and git GUIs without wrapping. It's long enough for descriptive messages but short enough to enforce conciseness. This makes git log and GitHub history readable
|
|
116
|
+
- **Trade-off**: Sometimes you want longer descriptions. But that's what the body is for
|
|
117
|
+
- **When to override**: For teams that prefer shorter (72 chars) or longer headers. But 100 is a good standard
|
|
118
|
+
|
|
119
|
+
**Flexible Scope Requirement**: Optional by default
|
|
120
|
+
|
|
121
|
+
- **Why**: Not all changes fit neatly into scopes. Making scopes optional allows quick commits while still enabling teams to enforce scopes when structure is important (like in monorepos where scope = package name)
|
|
122
|
+
- **Trade-off**: Scopes aren't enforced unless explicitly enabled
|
|
123
|
+
- **When to override**: Set `scopeRequired: true` for monorepos or projects where scope categorization is important
|
|
124
|
+
|
|
99
125
|
## 📋 Configuration Details
|
|
100
126
|
|
|
101
127
|
### Commit Message Format
|