feat(helpline104-api): implement commit message linting and automation #45
Conversation
WalkthroughThis change introduces a comprehensive commit message linting and enforcement system to the project. It adds configuration and tooling for Commitlint, Husky, and Commitizen, along with a GitHub Actions workflow to automatically check commit message compliance on pull requests. Documentation is updated to guide developers on setting up and using these tools, and Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant Husky
participant Commitlint
participant GitHub Actions
Developer->>Husky: git commit
Husky->>Commitlint: Lint commit message
Commitlint-->>Husky: Pass/Fail
Husky-->>Developer: Allow/Block commit
Developer->>GitHub Actions: Open/sync PR
GitHub Actions->>Commitlint: Lint all PR commits
Commitlint-->>GitHub Actions: Pass/Fail
GitHub Actions-->>Developer: PR status update
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: 2
🧹 Nitpick comments (8)
.gitignore (1)
24-26: Suggestion: Broaden npm debug log ignore pattern.
Consider using a wildcard to ignore rotated or versioned npm debug logs.node_modules/ -npm-debug.log +npm-debug.log*README.md (3)
43-46: Specify language for code block.
For syntax highlighting, addbashto the fenced code block for Node.js version checks.- ``` + ```bash node --version npm --version ```🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
43-43: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
50-53: Specify language for code block.
Addbashto the fenced code block for npm commands.- ``` + ```bash npm ci ```🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
50-50: Fenced code blocks should have a language specified
null(MD040, fenced-code-language)
83-85: Specify language for code block.
Addbashto the code fence for the Commitizen command.- ``` + ```bash npm run commit - ``` + ```.github/workflows/commit-lint.yml (1)
29-30: Remove trailing whitespace and add newline at EOF.
YAML lint reports trailing spaces on line 30 and missing newline at end-of-file.-run: | - npx commitlint --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbose +run: | + npx commitlint --from ${{ github.event.pull_request.base.sha }} --to ${{ github.event.pull_request.head.sha }} --verbose +🧰 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)
package.json (1)
1-21: Optional: Add a manual commit-lint script.
For convenience, add a script to manually run commitlint locally outside a Git hook."scripts": { ... + "lint:commit": "commitlint --from=HEAD~1 --to=HEAD --verbose" }This lets developers lint one or more commits on demand.
commitlint.config.js (2)
9-13: Subject-case restrictions
Currently you’re disallowing sentence-case, Start-Case, PascalCase, and UPPER-CASE in the subject, but allowing any other style (e.g. kebab-case or all-lowercase). If you’d prefer to enforce only lowercase (no hyphens), consider:-'subject-case': [2, 'never', ['sentence-case', 'start-case', 'pascal-case', 'upper-case']], +'subject-case': [2, 'always', 'lower-case'],
35-36: Remove trailing whitespace
There’s an extra space after the closing semicolon on line 36. Trimming it will clean up the file.
📜 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)
🪛 LanguageTool
README.md
[uncategorized] ~41-~41: The official spelling of this programming framework is “Node.js”.
Context: ...d npm** - Download and install from nodejs.org - Verify i...
(NODE_JS)
[grammar] ~67-~67: “Bug” is a singular noun. It appears that the verb form is incorrect.
Context: ... - feat: A new feature - fix: A bug fix - docs: Documentation changes - `styl...
(PCT_SINGULAR_NOUN_PLURAL_VERB_AGREEMENT)
[uncategorized] ~70-~70: Loose punctuation mark.
Context: ... changes (formatting, etc.) - refactor: Code changes that neither fix bugs nor ...
(UNLIKELY_OPENING_PUNCTUATION)
🪛 markdownlint-cli2 (0.17.2)
README.md
43-43: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
50-50: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
82-82: Fenced code blocks should have a language specified
null
(MD040, fenced-code-language)
🔇 Additional comments (5)
commitlint.config.js (5)
1-3: Extending the conventional config correctly
The file properly extends@commitlint/config-conventionalto inherit the standard Conventional Commits ruleset.
4-8: Enforcing body & footer formatting
You’ve added rules to require leading blank lines and limit line lengths in the body (100 chars) and footer (100 chars). This maintains readability—warning for missing blank lines and errors for line-length violations.
14-15: Prevent empty/trailing-period subjects
The rulessubject-empty: [2, 'never']andsubject-full-stop: [2, 'never', '.']correctly enforce that commits have a non-empty subject without a trailing period, matching Conventional Commits.
16-21: Type-case and emptiness rules
Requiring lowercase commit types (type-case) and disallowing empty types (type-empty) ensures consistency in the<type>(<scope>): <subject>structure.
22-34: Allowed types enumeration
Yourtype-enumlist covers the standard Conventional Commit types. If your project later introduces custom types (e.g.,hotfix), remember to update this array.
| @@ -0,0 +1 @@ | |||
| npx --no -- commitlint --edit $1 No newline at end of file | |||
There was a problem hiding this comment.
Invalid npx flag for commitlint invocation.
The Husky hook uses npx --no -- commitlint, but the recommended flag is --no-install. This may cause hook failures.
Apply this diff:
-npx --no -- commitlint --edit $1
+npx --no-install commitlint --edit "$1"📝 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" |
| "test": "echo \"Error: no test specified\" && exit 1", | ||
| "prepare": "husky", | ||
| "commit": "cz" | ||
| }, |
There was a problem hiding this comment.
Fix Husky prepare script.
Husky v7+ requires husky install in the prepare step to set up Git hooks. Using husky alone may not initialize the hooks.
- "scripts": {
- "test": "echo \"Error: no test specified\" && exit 1",
- "prepare": "husky",
- "commit": "cz"
+ "scripts": {
+ "test": "echo \"Error: no test specified\" && exit 1",
+ "prepare": "husky install",
+ "commit": "cz"After updating, run
npm installto trigger thepreparescript and create the.huskydirectory with your hooks.
📝 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.
| "test": "echo \"Error: no test specified\" && exit 1", | |
| "prepare": "husky", | |
| "commit": "cz" | |
| }, | |
| "scripts": { | |
| "test": "echo \"Error: no test specified\" && exit 1", | |
| "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
@G4URAV001 Thank you for the correction! You're absolutely right. For Husky v9, the correct configuration is "prepare": "husky" as you've implemented, and husky install is deprecated in v9.
I appreciate you providing the reference to the official documentation. Your implementation is correct, and I apologize for the confusion in my previous comment.
🌐 Web query:
husky v9 installation "prepare" script configuration
💡 Result:
Husky v9 Installation and "prepare" Script Configuration
Husky v9 manages Git hooks in JavaScript projects and relies on the prepare script in your package.json to set up and install its hooks. Understanding how this script is configured—and what can and cannot be customized—is essential for a smooth installation, especially in collaborative or monorepo setups.
Default Behavior of prepare Script in Husky v9
- When you run
husky init(e.g.,npx husky initorpnpm exec husky init), Husky v9:- Creates a
.huskydirectory. - Adds a default
pre-commithook script. - Sets the
preparescript in yourpackage.jsontohusky(overwriting any existingpreparescript)[3][4][1].
- Creates a
- The
preparescript is used because it runs afternpm install, ensuring Husky is set up automatically for every user who installs dependencies[2][4].
Configuring or Customizing the prepare Script
- Custom
preparescripts are NOT supported. Husky v9's behavior is to always overwrite thepreparescript withprepare: husky, so you cannot have custom logic in this script alongside Husky[1]. - If your repository already has a
preparescript, it will be replaced. This is a known issue and there is no official workaround to merge custom prepare steps[1]. - If you need custom setup steps, you must run them separately from the standard Husky installation process, or manually set up Husky hooks as detailed below.
Workarounds and Manual Setup
If you require additional logic or custom commands during preparation, you must not rely on Husky’s automatic script and instead:
-
Manually set up Husky:
- Follow Husky’s manual setup guide to perform the three essential steps by hand[1].
- Then, you can use your own custom
preparescript that includes both your custom logic and Husky installation steps, for example:"scripts": { "prepare": "your-custom-setup && husky install" }
- This way, you control what happens in
prepare, but you assume responsibility for Husky setup[1][5].
-
In monorepos or custom directory setups:
- Adjust the
preparescript to target the correct location of your.gitor.huskydirectories, as needed[5]. - Example:
"scripts": { "prepare": "cd ../ && husky install frontend/.husky" }
- Adjust the
Handling CI Environments
- If you want to prevent
preparefrom failing in CI (wheredevDependenciesmight not be installed), you can use an OR fallback:This ensures the script does not cause the build to fail if Husky is not installed[2][6]."scripts": { "prepare": "husky || true" }
Summary Table: Husky v9 Prepare Script Behavior
| Scenario | Husky Installs / Overwrites | Customization | Workaround |
|---|---|---|---|
prepare script present |
Overwritten by Husky | No | Manual setup, combine steps |
Need multiple prepare actions |
Not supported by default | No | Manual setup, combine steps |
| CI environment | Fails if missing | Yes, with ` |
Key Takeaways
- Husky v9 enforces
prepare: huskyand does not support custom or multiple prepare scripts out of the box[1][3][4]. - If you need custom logic, adopt manual setup and move all required commands into your own
preparescript[1]. - Always run
npm run prepareafter updates to ensure hooks are correctly installed[5].
For ongoing issues and updates, monitor Husky’s official GitHub repository[1][8].
Citations:
- 1: Husky replaces my "prepare" script typicode/husky#1387
- 2: https://itenium.be/blog/dev-setup/git-hooks-with-husky-v9/
- 3: https://typicode.github.io/husky/get-started.html
- 4: https://javascript.plainenglish.io/migrating-husky-to-v9-33c1f02eb3a9
- 5: https://dev.to/zhangzewei/pre-commit-with-husky-lint-staged-2kcm
- 6: https://syntackle.com/blog/creating-git-hooks-using-husky-y6LKpN/
- 7: https://remarkablemark.org/blog/2024/02/04/how-to-migrate-from-husky-8-to-9/
- 8: https://github.com/typicode/husky
- 9: https://typicode.github.io/husky/
@G4URAV001 You're absolutely right, and I apologize for the incorrect suggestion. The web search confirms that for Husky v9, the correct configuration is indeed "prepare": "husky" as you've implemented, and the husky install command is deprecated in v9.
Thank you for providing the reference to the official documentation. Your implementation is correct, and I appreciate you taking the time to correct this misunderstanding.
✏️ Learnings added
Learnt from: G4URAV001
PR: PSMRI/Helpline104-API#45
File: package.json:5-8
Timestamp: 2025-04-25T16:54:00.028Z
Learning: Husky v9+ specifically requires "prepare": "husky" in package.json scripts, while "prepare": "husky install" was for Husky v8 and earlier versions. The install command is deprecated in v9 as documented at https://typicode.github.io/husky/how-to.html
Learnt from: G4URAV001
PR: PSMRI/Helpline104-API#45
File: package.json:5-8
Timestamp: 2025-04-25T16:54:00.028Z
Learning: Husky v9+ specifically requires "prepare": "husky" in package.json scripts, while "prepare": "husky install" was for Husky v8 and earlier versions. The install command is deprecated in v9 as documented at https://typicode.github.io/husky/how-to.html
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.
1 participant
📋 Description
Closes PSMRI/AMRIT#87
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