Comments (20)
I'm using commitizen
together with commitlint
on a project. Commitizen is setup with cz-conventional-changelog
, and commitlint
is setup with @commitlint/config-conventional
.
It would be great if somehow the rules of what a conventional commit message would be shared between those projects. Line length at 72 for instance is an annoying one because commitizen will let you type a subject > 72 lines, but then the pre-commit hook will reject it immediately after.
from cz-conventional-changelog.
Created PR (#75).
It allows config through the "config.commitzen" package.json key (the same place you specify "path" for the commitizen adapter). You can now configure the maxHeaderWidth, maxLineWidth, defaultType, defaultScope, defaultBody, and defaultIssues though the original environment variables support will override the config.
I also fixed a few issues with standardization required by the Conventional Commit standard that will fail with @commitlint/config-conventional
. The scope now is always lowercase (which is required). The subject will now start with a lowercase letter and any trailing dots are trimmed.
Regarding the length, the length allowed for the subject is now a calculated value based upon config.maxHeaderWidth - type.length - (scope ? scope.length + 2 : 0) + 2 // for the colon space
The number of allowed character is printed in the prompt message for the subject and as you type, the count of character shows in parens next to the input. When the length is equal to or less than the allowed amount, the string shows as green. Once you have gone over, it shows red. If you attempt to submit while its red, it will fail and ask you to reenter.
Regarding body wrapping, this is now configurable via the "maxLineWidth" parameter which will set the wrapping amount for both the body and footer (default set to 100 as it is now).
Honestly I believe the default should be 72 for both header and body but since its configurable, each project can decide on their own. You will need to set it to 72 to allow commitlint to always pass for the config-conventional.
from cz-conventional-changelog.
rather than fragmenting things further, a PR to this project would be a great idea for this
from cz-conventional-changelog.
I am open to the idea but I'd require placing it using the existing config loader (typically a key under package.json)
https://github.com/commitizen/cz-cli/blob/master/package.json#L23
Specifically I'd recommend namespacing it to the adapter.
config > commitizen > "cz-conventional-changelog" > maxLineWidthHeader
An adapter should then be passed any of the config options under its configuration path.
from cz-conventional-changelog.
I am looking at creating a PR to bring even more configuration options from commitlint.
Before doing this -- I am wondering if this would be desirable in this project?
I don't want to fragment this project unnecessarily.
from cz-conventional-changelog.
I'm not a maintainer of this project, just a user, but I whole-heartedly welcome any contributions that aligns it with commitlint.
from cz-conventional-changelog.
The default in git of max line width is 50 for the subject and 72 chars for all other lines. It is described in How to Write a Git Commit Message.
I agree, it would be nice if we could make the values configurable.
from cz-conventional-changelog.
I forked the repo and created a new npm package that allows you to configure the line length. It's name is cz-conventional-changelog-customizable.
from cz-conventional-changelog.
I can make a PR if one of the maintainers chime in and tell me how they want the line width configuration to look like.
from cz-conventional-changelog.
How does the config look in your fork, I'm open to any suggestions :)
from cz-conventional-changelog.
It's just a json file that specifies what the max line widths for header and body are with fallback to 100 characters.
from cz-conventional-changelog.
the situation @lwouis describes is exactly the situation my team is in as well.
however, to make matters worse, we use husky to run npm test
on the pre-commit
hook. since git fires pre-commit
before commit-msg
, the feedback we get about the length is delayed, so it ends up being even more wasteful.
i agree that using a project's commitlint config, if present, would be ideal. although, it might be a little less than simple to handle configs that extend others, like mine.
from cz-conventional-changelog.
also, i still think the best option is for the prompt to give some feedback while typing the message, as suggested in commitizen/cz-cli#178 so that the message isn't just truncated w/o the developer getting some sort of warning (which is why i do see value in the commitlint
length check).
from cz-conventional-changelog.
@yinzara i've been meaning to try out your PR on my personal projects, but havent had a chance to yet. It sounds very close to what I would hope for, so I'm excited about it.
Since you mention commitlint and configuration, do you think it could be feasible for the default config to be pulled from what is built up in the commitlint config, when present? I think I would always want them to be configured consistently, so needing to configure commitizen separately feels like it would leave too easy of an opportunity for them to get out of sync.
Personally, i use my own shareable config for commitlint, so feel free to take a look at that in case my approach is different from yours in any way that would influence feasibility.
from cz-conventional-changelog.
Your wish is.... well I'm happy to add things I also agree are awesome.
I've now added optional parsing of commitlint config itself (still can be overwritten by the config I added or the environment variable config). If commitlint is not present, it fails gracefully and continues to function normally. If it is, it defaults the value based on the commitlint config (no matter how complex your import is as it uses commitlint itself to get the config values).
I also added test cases which required a mocking framework (I used mock-require since it supported mocking default functions [sinon does not]).
The only config parameter supported is the commitlint rule "header-max-length" (i.e. the maxHeaderWidth config parameter)
from cz-conventional-changelog.
Oh and I forgot, related to issue #43 . I have added additional questions that only appear if you add a breaking change or an issue reference but have no description. It defaults the value to "-" but prompts you to change it.
from cz-conventional-changelog.
Note regarding versions of things. As we have always supported Node 4 for this project, I've attempted to keep Node 4 compatibility. The @commitlint/load module (which handles commitlint loading) only appeared in version 6.1.1 of commitlint which doesn't support Node 4 (it's node 6 and higher). The library already failed gracefully however the test cases were breaking. I added a semver checking and added separate test cases for any Node before 6 that test that it fails gracefully.
from cz-conventional-changelog.
Btw I also removed the "console.log" statement that appears every time the CLI is run. Since it now handles line wrapping and heading max width automatically, I felt it wasn't required and it was making running the test cases look awful.
from cz-conventional-changelog.
Btw if you run code coverage, you'll see there is now 100% coverage ;-)
from cz-conventional-changelog.
Closing stale issues
from cz-conventional-changelog.
Related Issues (20)
- Consider switching to a different prompt library HOT 3
- NPM audit reports low vulnerability in dependency HOT 3
- require('@commitlint/load') does not work properly anymore HOT 9
- Better Tests HOT 1
- 2nd source of lodash 4.17.14 vulnerability
- Commitlint config loading not working
- Something maybe wrong with the code in engine.js
- Vulnerability Prototype Pollution HOT 2
- Add config option to extend instead of overriding HOT 1
- Add prompter option to append .gitmessage to commits
- Add support for optional exclamation mark (!) HOT 1
- Dependency Dashboard
- Action Required: Fix Renovate Configuration
- [Feature request] Add autocomplete feature
- Vulnerability warnings with ansi-regex and minimist HOT 11
- Title config in package.json is not working anymore, but still remaining in README.md
- the adapter does not respect the commit types defined in .versionrc
- add an option to customize scopes HOT 1
- Add additional prompt for co-authors
- Skip some of the questions with configuration
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cz-conventional-changelog.