feat(identify-api): implement commit message linting and automation #95
Conversation
WalkthroughThis update introduces automated commit message linting and enforcement into the project. It adds configuration files for Commitlint, Husky, and Commitizen, sets up a GitHub Actions workflow to check commit messages on pull requests, and documents the process in the README. The Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant Git
participant Husky
participant Commitlint
participant GitHub
participant GitHub Actions
Developer->>Git: git commit
Git->>Husky: Trigger commit-msg hook
Husky->>Commitlint: Lint commit message
Commitlint-->>Husky: Pass/Fail
Husky-->>Git: Allow/Block commit
Developer->>GitHub: Push branch / Open PR
GitHub->>GitHub Actions: Trigger commit-lint workflow
GitHub Actions->>Commitlint: Lint all PR commits
Commitlint-->>GitHub Actions: Pass/Fail
GitHub Actions-->>GitHub: Report status on PR
Possibly related issues
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
package.json (1)
4-8: Add a manual commitlint script for on-demand linting
It can be useful to run commitlint outside of CI or Git hooks. Consider adding:"scripts": { "test": "echo \"Error: no test specified\" && exit 1", "prepare": "husky install", "commit": "cz", + "lint:commit": "commitlint --from HEAD~10 --to HEAD --verbose" },This lets developers manually validate recent commits.
.github/workflows/commit-lint.yml (1)
29-30: Remove trailing spaces and add newline at EOF
Your workflow file is missing a newline at the end and has trailing whitespace on the--verboseline. Apply:- npx commitlint --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbose + npx commitlint --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbose +This satisfies YAML linters and best practices.
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 30-30: no new line character at the end of file
(new-line-at-end-of-file)
[error] 30-30: trailing spaces
(trailing-spaces)
commitlint.config.js (1)
18-34: Allowed Commit Types Reviewed
The listed types (build,chore,ci,docs,feat,fix,perf,refactor,revert,style,test) are standard. If your workflow ever uses dedicated release commits, consider adding areleasetype to this enum.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (6)
.github/workflows/commit-lint.yml(1 hunks).gitignore(1 hunks).husky/commit-msg(1 hunks)README.md(2 hunks)commitlint.config.js(1 hunks)package.json(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.35.1)
.github/workflows/commit-lint.yml
[error] 30-30: no new line character at the end of file
(new-line-at-end-of-file)
[error] 30-30: trailing spaces
(trailing-spaces)
🔇 Additional comments (8)
package.json (1)
14-20: Verify Commitizen configuration path
Double-check that theconfig.commitizen.pathcorrectly points tocz-conventional-changelogundernode_modules. If you ever move or upgrade the adapter, update this accordingly..gitignore (1)
37-40: Excluding Node.js artifacts
The new section correctly ignoresnode_modules/andnpm-debug.log, preventing large directories and debug logs from being committed.README.md (1)
37-52: Document commit hook setup clearly
The new "Commit Message Hooks" section is concise, accurate, and guides contributors through installing dependencies and using the interactive commit flow.commitlint.config.js (5)
1-3: Configuration Setup Looks Good
Extending@commitlint/config-conventionalis the correct approach to inherit the conventional commit rules. No issues found in the module export or extends configuration.
4-8: Line Length and Blank-line Rules Are Appropriate
The rules for enforcing blank lines before body/footer and capping their line lengths (100 chars), as well as the 100-character header max length, align with the PR objectives to maintain readability.
9-15: Subject Rules Enforce Consistency
The configuration correctly prohibits unwanted casing styles and trailing periods in the subject line, and disallows empty subjects. This ensures concise, well-formatted commit messages.
16-17: Type Case and Non-emptiness Enforced
Requiring lowercase commit types and disallowing empty types is consistent with Conventional Commits standards.
35-36: Closing Syntax – No Action Needed
These lines only close the object and file. No changes required here.
| "prepare": "husky", | ||
| "commit": "cz" |
There was a problem hiding this comment.
Fix Husky prepare script to properly install hooks
The current prepare script ("husky") will invoke the CLI help rather than initializing Git hooks. According to Husky v7+ docs, it should be:
-scripts": {
- "prepare": "husky",
+scripts": {
+ "prepare": "husky install",This ensures hooks in .husky/ are hooked into the repository on npm install.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "prepare": "husky", | |
| "commit": "cz" | |
| "prepare": "husky install", | |
| "commit": "cz" |
There was a problem hiding this comment.
The project is using Husky v9.1.7, which specifically requires:
"prepare": "husky"
The suggested "prepare": "husky install" is for Husky v8 and earlier.
From the official Husky v9 documentation:
For v9: npm pkg set scripts.prepare="husky"
The install command is deprecated in v9
Reference: https://typicode.github.io/husky/how-to.html
There was a problem hiding this comment.
🧩 Analysis chain
You're absolutely right, @G4URAV001! I apologize for the incorrect suggestion. After checking the Husky v9 documentation, I can confirm that for Husky v9.1.7, the correct prepare script is indeed "prepare": "husky" without the "install" command.
The documentation clearly states that for v9, the recommended setup is:
npm pkg set scripts.prepare="husky"
And as you correctly pointed out, the "install" command is deprecated in v9.
Thank you for the correction and for providing the reference documentation. The current implementation in your package.json is correct for Husky v9.1.7.
🌐 Web query:
Husky v9 documentation prepare script
💡 Result:
Husky v9 "prepare" Script: Documentation and Usage
Summary:
With Husky v9, setting up Git hooks is streamlined via the "prepare" script in package.json, the husky NPM package, and npx husky init. This approach leverages Git's core.hooksPath and ensures a consistent, team-friendly setup.
Purpose of the "prepare" Script
- The
"prepare"script inpackage.jsonensures that after anynpm install, Husky sets up the necessary Git hooks for all users of the repository[1][3][5]. - Its presence automates hook installation, providing a frictionless experience for all developers interacting with the project.
What Does Husky v9 Do When Initialized?
-
Installation:
Install Husky as a development dependency:npm install --save-dev huskyor with your preferred package manager:
yarn add --dev husky pnpm add --save-dev husky bun add --dev husky -
Initialization:
Run the init command:npx husky initThis will:
- Add or update
"prepare": "husky"in yourpackage.json. - Create a
.husky/directory and add a samplepre-commithook. - Set Git's
core.hooksPathto.husky/_automatically[1][3][5].
Example
package.jsonsnippet after initialization:"scripts": { "prepare": "husky" }
- Add or update
-
How It Works:
- After every
npm install, the"prepare": "husky"script ensures Husky sets up and maintains the hooks directory and links the shell scripts. - Actual Git hook scripts live in
.husky/(e.g.,.husky/pre-commit), but Husky internally uses.husky/_for its operational files[3][5].
- After every
Key Points & Best Practices
- Do not manually edit or remove
.husky/_— Husky manages this directory. - Place your custom hook scripts (e.g.,
pre-commit,pre-push) directly in the.husky/folder[1][3][5]. - The
"prepare": "husky"script is the recommended form for Husky v9 (previous versions used"prepare": "husky install")[5]. - For CI/CD environments where
devDependenciesmight not be installed, you can make the script non-failing:"prepare": "husky || true"
Example Migration to Husky v9
-
Update Husky:
npm install --save-dev husky@latest -
Ensure the Correct Prepare Script:
"scripts": { "prepare": "husky" }
-
Initialize Husky:
npx husky initThis creates the necessary directories and a sample hook file[1][3][5].
-
Customize Hooks:
Edit.husky/pre-commitand other hook files as needed.
References to Official Documentation
- Official Husky documentation on getting started[1]
- Guide to Git hooks with Husky v9[3]
- Migration guide and usage notes[5]
In summary:
With Husky v9, the "prepare": "husky" script in package.json is central to setup. After each dependency install, it ensures Husky hooks are properly configured, hooks live in .husky/, and all operational details are handled automatically for both local development and shared team environments[1][3][5].
Citations:
- 1: https://typicode.github.io/husky/get-started.html
- 2: docs: confusion on v9 usage with husky init typicode/husky#1535
- 3: https://itenium.be/blog/dev-setup/git-hooks-with-husky-v9/
- 4: https://typicode.github.io/husky/
- 5: https://javascript.plainenglish.io/migrating-husky-to-v9-33c1f02eb3a9
- 6: https://github.com/typicode/husky
@G4URAV001 You're absolutely right! Thank you for the correction and reference.
I can confirm from the documentation that Husky v9 indeed uses "prepare": "husky" and the install command is deprecated in v9. This differs from v8 and earlier versions which used "prepare": "husky install".
Your current implementation is correct for Husky v9.1.7. I apologize for the incorrect suggestion.
✏️ Learnings added
Learnt from: G4URAV001
PR: PSMRI/Identity-API#95
File: package.json:6-7
Timestamp: 2025-04-25T16:49:37.488Z
Learning: For Husky v9+, the correct prepare script is "prepare": "husky" (without "install"). The "install" command is deprecated in v9. For v8 and earlier versions, the command was "prepare": "husky install".
Learnt from: G4URAV001
PR: PSMRI/Identity-API#95
File: package.json:6-7
Timestamp: 2025-04-25T16:49:37.488Z
Learning: For Husky v9+, the correct prepare script is "prepare": "husky" (without "install"). The "install" command is deprecated in v9. For v8 and earlier versions, the command was "prepare": "husky install".
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| @@ -0,0 +1 @@ | |||
| npx --no -- commitlint --edit $1 No newline at end of file | |||
There was a problem hiding this comment.
Use the correct npx flag and quote the commit file
The hook currently uses --no, which is not a valid npx flag and may not prevent installs. Please update to:
- npx --no -- commitlint --edit $1
+ npx --no-install commitlint --edit "$1"This ensures the locally installed commitlint is used without side-effect installs and handles filenames with spaces safely.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| npx --no -- commitlint --edit $1 | |
| npx --no-install commitlint --edit "$1" |
| name: Commit Compliance | ||
|
|
||
| on: | ||
| pull_request: | ||
| types: [opened, synchronize, reopened] | ||
|
|
||
| jobs: | ||
| commitlint: | ||
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - name: Checkout code with submodule | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| ref: ${{ github.event.pull_request.head.ref }} | ||
| repository: ${{ github.event.pull_request.head.repo.full_name }} | ||
| submodules: true | ||
| fetch-depth: 0 | ||
|
|
||
| - name: Setup Node.js | ||
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: 18 | ||
|
|
||
| - name: Install dependencies | ||
| run: npm ci --legacy-peer-deps | ||
|
|
||
| - name: Run commitlint on PR | ||
| run: | | ||
| npx commitlint --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbose No newline at end of file |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify presence of commitlint.config.js
Ensure that commitlint.config.js exists in the repository root and correctly extends @commitlint/config-conventional. You can run:
This confirms your CI and local hooks have the intended rules.
🏁 Script executed:
#!/bin/bash
# Check for commitlint config
if [[ ! -f commitlint.config.js ]]; then
echo "Error: commitlint.config.js is missing"
exit 1
else
echo "commitlint.config.js found"
fiLength of output: 96
#!/bin/bash
# Verify that commitlint.config.js extends @commitlint/config-conventional
grep -n "extends" commitlint.config.js || echo "No 'extends' key found"🏁 Script executed:
#!/bin/bash
# Verify commitlint.config.js extends @commitlint/config-conventional
rg -n "extends\s*:\s*['\"]@commitlint/config-conventional['\"]" commitlint.config.js || echo "Error: commitlint.config.js does not extend @commitlint/config-conventional"Length of output: 251
Add conventional commit rules to commitlint.config.js
The file exists but doesn’t extend the official conventional preset, so CI won’t enforce your team’s commit guidelines. Please update commitlint.config.js to include:
module.exports = {
extends: ['@commitlint/config-conventional'],
// …any custom rules here
};• File: commitlint.config.js
• Line(s): at the top of the exported config
🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 30-30: no new line character at the end of file
(new-line-at-end-of-file)
[error] 30-30: trailing spaces
(trailing-spaces)
📋 Description
Closes PSMRI/AMRIT#90
JIRA ID: issue link
This PR implements commit message linting and automation for all contributors in the API repositories using Commitlint, Husky, and Commitizen. The aim of this initiative is to enforce a consistent and readable commit history, improving collaboration and enabling future automated changelogs and CI/CD processes. This setup aligns with the practices followed across all C4GT Community repositories.
Every commit in API repositories will follow the defined structure (e.g., Conventional Commits).
Husky will block non-compliant commit messages locally.
Contributors will use Commitizen (cz) to follow a guided commit format.
GitHub Actions will fail PR checks if commit messages do not follow the required format.
All changes will be compatible with the existing CI/CD pipelines, ensuring smooth integration.
✅ Type of Change
ℹ️ Additional Information
• Added commitlint.config.js with conventional commit rules.
• Configured Husky to run Commitlint on every commit via .husky/commit-msg .
• Set up Commitizen with configuration in package.json for interactive commit prompts.
• Added GitHub Actions workflow .github/workflows/commit-lint.yml to check commit messages on PRs.
• Updated package.json and package-lock.json with required dev dependencies:
- @commitlint/config-conventional
- commitizen
- cz-conventional-changelog
Testing & Validation
• Invalid commit messages are blocked locally with clear lint errors.
• Interactive commit flow works via npm run commit or npx cz .
• GitHub Actions workflow correctly fails PRs with non-compliant commit messages.
• No disruption to existing build or CI pipelines.
Summary by CodeRabbit