commitizen/cz-conventional-changelog

A commitizen adapter for the angular preset of https://github.com/conventional-changelog/conventional-changelog

cz-conventional-changelog's Issues

Should be imperative mood, there is no such thing as imperative tense

cz-conventional-changelog/engine.js

Line 64 in d4bf98e

message: 'Write a short, imperative tense description of the change:\n'

Just a nitpick, but it would be an improvement to re-word this message, perhaps with a brief example in the line. At the very least, this should be replaced with "mood" instead of "tense". I like how this example explains the intent of this type of commit message (https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/SubmittingPatches):

Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behavior. Try to make sure your explanation can be understood
without external resources. Instead of giving a URL to a mailing list
archive, summarize the relevant points of the discussion.

update conventional-commit-types dependency

Version 3.0.0 of conventional-commit-types removes the improvement commit type. For consistency with the conventional commits spec, we'd like to see this change in the commitizen CLI, and since it's a breaking change we'd need to update the dependency here. Would this be a breaking change here, too?

cc @AndersDJohnson

About subprojects

Hello！
My main project is called shop and subproject is called shop-app.
When I run git cz under the subproject shop-app,
The commit url in the created CHANGLOG.md points to the main project but not the subproject.

I expect is :https://gitlab.com/qianqu/shop/shop-app/commit/6cba4ee)
But it became: https://gitlab.com/qianqu/shop/commit/6cba4ee)

The a-tag generated at the head of the file is also what I don't want.

what should I do？

sources?

any reason the sources disappeared?

fails when used with commitizen < 2.8

It seems commitizen is a bit strange thing and does not follow so strictly semver. And they even dropped support for node<4 with no major bump. But anyway. So my workaround to get all things working is to lock commitizen to ~2.7.0, but then this package fails, cuz maybe commitizen 2.7 does not use promises?

Versions 1.1.3 and 1.1.4: Error loading "word-wrap"

Since upgrading to 1.1.4 this morning I get the following error.

$ git-cz
Potentially unhandled rejection [3] Error: Error loading "word-wrap" at file:/path/to/my/project/node_modules/cz-conventional-changelog/word-wrap.js
Error loading "word-wrap" from "index" at file:/path/to/my/project/node_modules/cz-conventional-changelog/index.js
ENOENT, open '/path/to/my/project/node_modules/cz-conventional-changelog/word-wrap.js'
    at Error (native)

(I realise this report is quite brief, but I'm not sure what else to add. Please ask for any more info you need and I'll get it for you).

Thanks a lot for this great tool.

Add validation of answers: disallow having BREAKING CHANGE but no body

Take a commit message like this:

feat: something

BREAKING CHANGE: some breaking change

The BREAKING CHANGE section is not recognized by the tools that analyze commits, e.g. semantic-release, because BODY part of the commit is missing and they think the FOOTER is actually a BODY.
Is this a correct behavior of those tools or in other words should it be allowed to specify FOOTER without providing BODY?

If this should be forbidden, we could add the validation function to our inquirer code to validated these cases

Please consider the case with new npm and flat dependencies

It looks like this line will brake with new npm and flat dependencies https://github.com/commitizen/cz-conventional-changelog/blob/master/index.js#L3

Make lower-casing of scope optional

Using cz-conventional-changelog with non-JS projects where components and file names may be cased is problematic due to the forced lower-casing of the value typed in for the scope prompt. Lower-casing should be optional, although defaulting to on is fine.

Add "content" case

Hi,

I've been using the Angular commit messages convention fro more than a year now, and I find it great. If I understand correctly, this pretty much mirrors cz-conventional-changelog prompts.

Imho, there's one type of commits that is very relevant though, and it's missing from the list: the "content" type.

Every time I'm working on an app or a website and I need to commit changes to its static content (e.g. text in a page, pictures, titles, etc.) I can't find a good fit in the existing commit types included in the list.

In fact, it's neither "feat", nor "style", nor "docs". Apart from this, I've found the list to be pretty exhaustive.

Therefore, I propose to include the "content" type in the list, with the description "A UI content change that only affects static text or images" (or something similar).

Please let me know your thoughts, and if you'd like me to create a PR for it.

Thanks! Cheers :)

Add WIP as a type of change.

There should be a work in progress tag. I think.

Release new version

This needs to be released. Do you have any problem with me doing that? I'll do it in 10 minutes if you don't respond!!! 🕚 💣

[skip ci] option?

Wondering if it would be useful to display a conditional prompt for docs & chore to add [skip ci] option.

I guess most of the time a build is unnecessary for chore and docs changes.

Longer description is split into multiple paragraphs

I don't know if this is related to #13, but the longer descriptions are being split into multiple paragraphs, as in:

feat(?): ...

longer description line1

longer description line2

This is also reproducible by doing

git commit -m "feat(?): ..." -m "longer description line1" -m "longer description line2"

The git-commit docs say that multiple -m parameters are interpreted as paragraphs, which seems to be consistent with the above command results. Maybe git is interpreting the newlines added as new paragraphs? Also, it seems to be squashing \n\n into a single \n, as there is no difference between the output from the longer description and the separation between it and the subject.

I am using Windows 10 and git 2.9.0.windows.1

Consider switching to a different prompt library

Currently, Inquirer.js, the library you are using to display prompts, has a unfixed bug that has remained silent since a year. This bug causes the questions to duplicate/not get overwritten/not get cleared properly anytime a key is pressed, resulting in a unbelievably awful experience.
Looking forward, I don't believe that issue will receive a lot of attention; it appears all Inquirer maintainers don't use Windows which seems to correlate to the error message.
To prove this, I tried running cz-conventional-changelog multiple times in different command line environments (PowerShell 6, PowerShell Core 6, PowerShell 7, Git Bash, CMD, Terminus, Hyper) and all of them (even the bash-like ones) share the same problem.
It appears to originate from calls in git hooks (in my case via husky), but also from npm script calls (in the package.json file). This leaves me and other Windows users only with either calling git-cz manually from the command line before we commit, without any control, or by ignoring the issue.
I'd appreciate if you could move towards a other library that also supports prompts in git hooks, since this seems like a mandatory feature to me.

rename this to angular adapter?

Since conventional-changelog has many presets and angular is one of them.

`answers. breakingBody` and `answers. issuesBody` does not affect the commit message at all.

cz-conventional-changelog/engine.js

Lines 139 to 154 in e7bd546

	{
	type: 'input',
	name: 'breakingBody',
	default: '-',
	message:
	'A BREAKING CHANGE commit requires a body. Please enter a longer description of the commit itself:\n',
	when: function(answers) {
	return answers.isBreaking && !answers.body;
	},
	validate: function(breakingBody, answers) {
	return (
	breakingBody.trim().length > 0 ||
	'Body is required for BREAKING CHANGE'
	);
	}
	},

answers.breakingBody does not affect the commit message at all.

cz-conventional-changelog/engine.js

Line 207 in e7bd546

var body = answers.body ? wrap(answers.body, wrapOptions) : false;

I wrote breakingBody but found this doesn't make any sense. I read the code and I can't understand the meaning of this existence.

I find the issue #43 and #75.

Shouldn't the body be combined like this?

var b = answers.body || answers.breakingBody || answers.issuesBody
var body = b ? wrap(b , wrapOptions) : false; 

Add tests

This repository should contain tests so that something breaking like in #20 does not happen.

how to fix this error?

thanks

Not working when we are commiting with GIT GUI

Hi Every one,

I have used husky and commitizen in my project, when i try to make some commits , from git bash it is executing the hooks properly by prompting the questions (which is expected ), but when i try to commit from GIT GUI , it is skipping the "commitmsg" hook which in turn triggers "cz-conventional-changelog" to prompt the required questionaire.

Kindly help me out .

Issues closed by this change

I think I have configured correctly and when I run git cz (or npm run commit following Kents lessons), and when I enter 'closes #1' for (for breaking changes or issues closed), it does not get added to commit log. Only the scope and the short message is committed to the log . My git log does not breaks into lines and does not show the issues closed. Anything I am missing?.

Date: Wed Oct 7 11:47:27 2015 +1100
chore(releasing): showing short message only
Date: Wed Oct 7 11:25:37 2015 +1100
chore(releasing): add travis config conventional

Use conventional-commit-types

You may wish to integrate my new conventional-commit-types module which exposes a simple list of valid commit types used in this module (plus revert per Angular conventions).

I wanted a standalone module for these so I could use them in other tools, e.g. my new conventional-commit-types-cli. Alternatively, this module could be refactored to expose them, if you prefer that.

I can consider giving ownership of these new repos and modules to @commitizen.

chore: release new version to npm

The commit message length validation would be awesome, if it was accessible via the latest npm version.

Update README with disableScopeLowerCase option

As #96 has now been merged in, should the README be updated to include information about disableScopeLowerCase?

I'm happy to create a PR for this 😄

Link in repo description is broken

Is it possible to add a method for showing the branch name with each line?

I and all of my coworkers would LOVE for the changelog to include the branch name the work was committed to within the changelog. Is this possible?

Supporting multiline for conventional changelog

Hi @jimthedev,

This is in follow-up to commitizen/cz-cli#398 which I know you closed it and forwarded here which is I'm opening it in the relevant place for another discussion.

I believe that this adapter is inspired and follows Angular guideline for commits, which clearly allows multilines. Obviously it's easy to fork this adapter and make the change but it would be better IMHO to just update this adapter to work according to expected semantics for commits.

Example commit: angular/angular.js@0694af8

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

Add config option for custom types

I can see you're currently using angular's commit types (through npm package conventional-commit-types) and I think it would be a nice addition to add support for own commit types - either a config option like "additionalTypes" that would allow us to just add more types on top of the ones that are already in conventional-commit-types or a simple config option like "types" that would be used instead of conventional-commit-types.

Note that this isn't a request that requires you to support other conventional-changelog conventions and their different syntaxes, but just a request for an option that would allow people to extend already existing types with their own.

To add a little context, personally I would use this to add "enhance" type:

"enhance": {
    "description": "A code change that improves current functionality",
    "title": "Enhancements"
}

Error loading "word-wrap"

I got this error when using version 1.1.1, everything work fine in 1.1.0. I think it should load wordwrap/index.js instead of wordwrap.js

Potentially unhandled rejection [3] Error: Error loading "word-wrap" at file:/.../node_modules/cz-conventional-changelog/word-wrap.js
Error loading "word-wrap" from "index" at file:/.../node_modules/cz-conventional-changelog/index.js
ENOENT: no such file or directory, open '/.../node_modules/cz-conventional-changelog/word-wrap.js'
    at Error (native)

$ node -v  
v4.1.1

cz.prompt(...).then is not a function

Getting the following error on [email protected]:

node_modules/cz-conventional-changelog/index.js:79
    ]).then(function(answers) {
       ^

TypeError: cz.prompt(...).then is not a function
    at module.exports.prompter (node_modules/cz-conventional-changelog/index.js:79:8)
    at commit (.nvm/versions/node/v5.10.1/lib/node_modules/commitizen/dist/commitizen/commit.js:68:5)
    at .nvm/versions/node/v5.10.1/lib/node_modules/commitizen/dist/cli/strategies/git-cz.js:89:30
    at .nvm/versions/node/v5.10.1/lib/node_modules/commitizen/dist/commitizen/staging.js:30:5
    at .nvm/versions/node/v5.10.1/lib/node_modules/commitizen/node_modules/gulp-git/lib/exec.js:27:5
    at ChildProcess.exithandler (child_process.js:193:7)
    at emitTwo (events.js:100:13)
    at ChildProcess.emit (events.js:185:7)
    at maybeClose (internal/child_process.js:850:16)
    at Socket.<anonymous> (internal/child_process.js:323:11)

v1.1.5 appears to work as expected.

Spam printed to standard out during install

The following message may print to standard out during installation:

Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library!

The project needs your help! Please consider supporting of core-js on Open Collective or Patreon: 
> https://opencollective.com/core-js 
> https://www.patreon.com/zloirock 

Also, the author of core-js ( https://github.com/zloirock ) is looking for a good job -)

Here's the related issue and the dependency chain:

├─┬ [email protected]
│ ├─┬ @commitlint/[email protected]
│ │ ├── @commitlint/[email protected]
│ │ ├─┬ @commitlint/[email protected]
│ │ │ ├── @types/[email protected]
│ │ │ ├─┬ [email protected]
│ │ │ │ ├─┬ [email protected]
│ │ │ │ │ └── [email protected]
│ │ │ │ └── [email protected]
│ │ │ ├── [email protected]
│ │ │ ├── [email protected] deduped
│ │ │ └─┬ [email protected]
│ │ │   └─┬ [email protected]
│ │ │     └── [email protected]
│ │ ├─┬ [email protected]
│ │ │ ├── [email protected]

Please consider removing the dependency causing the verbose (and spammy) message to print to standard out during installation of this module.

Split Breaking Changes and issues closed into two separate questions

The idea behind doing this is that if the user has a breaking change, you could auto prefix it with BREAKING CHANGE text. Often times there are typos while writing this text in all caps.

original issue: commitizen/cz-cli#192

feat: use existing message

"In my personal opinion, users of cz-cli would probably expect that the -m flag would be inserted as the 'short' message." - @raibutera

See more of the original report and discussion here:
commitizen/cz-cli#3

The cli needs to have some sort of programatic api to pass things into adapters or at least we need to pass in rawArgs and args. Currently we break the prompter message signature each time we need to pass more data into the prompter. This is ok since at least it signals a breaking change, but it would be nice not to need to major version bump when an adapter wants more info from us (should just be a feature / new object key).

stop lowercasing description if second letter is also uppercase

Currently, we lowercase the whole description of a commit, but sometimes description starts with an abbreviation and lowercasing makes it look bad:

Let's add an additional check, is the second letter uppercase, and if so, skip the lowercase operation. I'm talking about the line https://github.com/commitizen/cz-conventional-changelog/blob/master/engine.js#L27

"longer description" and "breaking changes" are not included in the commit message

I am using Windows 7, and when running the git cz command with the cz-conventional-changelog adapter - the "longer description" and "breaking changes" are not included in the commit message.

I debugged it a little and found that the problem is with concatenating the \n\n to the message.

commit(head + '\n\n' + body + '\n\n' + footer);

Anything after a \n character is not included in the commit.
It works if I switch it to commas like this:

commit(head + ',' + body + ',' + footer);

https://github.com/commitizen/cz-conventional-changelog/blob/master/index.js#L98

Bug, subject converted to lowercase

Function filterSubject converts all inputs to lower case.
I want to keep my subject sentence cased.

[Feature] Selector for scope according to scope-enum rule

When the scope list is defined in the scope-enum rule, we could then have a selector like the type.

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

split out the commit message generation part

I'd be keen to provide a different prompter to the same changelog format – adding a bit of additional information.

Would you be interested in a PR that splits out the part that generates a commit message? With this, we'd be able to customise the prompt, and build on top of conventional-changelog as a commit message format.

Thanks for your work maintaining this!

Make max line width configurable

As far as I've seen, 72 characters is a well known default. Is there a reason why this adapter hardcodes 100? I'd be awesome if it was at least configurable.

Using double quotes in a message breaks the commit

The dump containing the error.

npm run commit

> [email protected] commit /Users/jcummins/projects/build-release/cz-cli
> git-cz

[email protected], [email protected]


Line 1 will be cropped at 100 characters. All other lines will be wrapped after 100 characters.

? Select the type of change that you're committing: fix:      A bug fix
? Denote the scope of this change ($location, $browser, $compile, etc.):
 build
? Write a short, imperative tense description of the change:
 fix the travis build git config
? Provide a longer description of the change:
 TravisCI gives a "Please tell me who you are" error if you don't set up git config username. This adds it.
? List any breaking changes or issues closed by this change:
 Part of #28
{ [Error: Command failed: /bin/sh -c git commit -m "fix(build): fix the travis build git config

TravisCI gives a "Please tell me who you are" error if you don't set up git config username. This
adds it.

Part of #28"
error: pathspec 'tell' did not match any file(s) known to git.
error: pathspec 'me' did not match any file(s) known to git.
error: pathspec 'who' did not match any file(s) known to git.
error: pathspec 'you' did not match any file(s) known to git.
error: pathspec 'are error if you don't set up git config username. This
adds it.

Part of #28' did not match any file(s) known to git.
]
  killed: false,
  code: 1,
  signal: null,
  cmd: '/bin/sh -c git commit -m "fix(build): fix the travis build git config\n\nTravisCI gives a "Please tell me who you are" error if you don\'t set up git config username. This\nadds it.\n\nPart of #28"  ' }

New releases of cz-conventional-changelog since 3.0.1 do not take effect

At present, all releases of cz-conventional-changelog since 3.0.1 are useless since they behave exactly as if 3.0.1 was installed.

The reason for this is the circular dependency between cz-conventional-changelog and commitizen. Since there is a circular dependency, one of the projects must always depend on an older version of the other. commitizen depends on cz-conventional-changelog =3.0.1 (no version range), so the modules get installed like this:

node_modules
    commitizen (v4.0.3)
        node_modules
            cz-conventional-changelog (v3.0.1)
    cz-conventional-changelog (v3.1.0)

When the user runs git-cz, commitizen resolves cz-conventional-changelog from its own node_modules, and thus always gets v3.0.1, no matter what version the user's package depends on.

The most annoying consequence of this problem for me personally is that even though my projects depend on cz-conventional-changelog v3.1.0 I am still seeing "improvement" in the list of change types, even though that type was removed some time ago.

This circular dependency will also likely cause you endless churn from Greenkeeper as Greenkeeper alternately updates commitizen and cz-conventional-changelog to update to the latest version of the other project, which will trigger a release, which will trigger Greenkeeper to update the other project, and so on, endlessly. Likely the only reason this has not happened already is that the build is failing for commitizen/cz-cli#657.

Some ideas for fixing this:

• Remove the dependency on commitizen from cz-conventional-changelog. Perhaps commitizen could instead pass an instance of configLoader to plugins. I don't think it is a good idea for plugins to have to depend on commitizen for this.
• Change the dependency on cz-conventional-changelog from commitizen to a ^ range dependency (although this will probably not fix the potential for Greenkeeper churn).
• Remove the dependency on cz-conventional-changelog from commitizen - is this really required?

Refactor the adapter to allow extension

I'd like to add to the adapter, but it's not granular enough for me to depend on specific parts. I'd like to depend on the prompting utility separately from the formatting one.

Add other flavours as prompt

At the moment you are using the angular way of writing commit messages.
Wouldn't it be an idea to configure what flavour (angular, atom, eslint, ember, jquery, jshint) should be used as prompt. This could be configured via package.json for example.

Allow for no, none, etc as answers to Breaking Changes

Either we need to accept no, none, etc or have a better message to indicate that no is the default answer if you hit enter at the breaking changes prompt.

This discussion prompted by this Twitter convo: https://twitter.com/commitizen/status/863195437498609666

Cannot find module 'commitizen'

after the latest release, i am seeing the following error when running git cz the same way i always have: Cannot find module 'commitizen'. I noticed the same problem when attempting to test this PR, but assumed at the time that I was simply pulling it down incorrectly during my attempt to test.

The simplest way to reproduce is probably to

• clone https://github.com/travi/javascript-scaffolder
• nvm install
• npm install -g commitizen (this is v4.0.2 for me currently)
• npm install
• make some code change and stage it for commit
• git cz
• see error

i'll try to find a chance to dig a bit to see if i can understand why this is happening for me and will add comments if i find anything, but wanted to at least get this opened in case the cause might be obvious to one of the core team.

Issue with related path

Hello! It looks like that tool expects that pakage.json is located in repository root folder. In my case it is not and I got "Cannot find module" error. Is it expected behavior?

Closing Issues not working

I went and read the Angular Contributing Guidelines and the Closing Issues via Commit Messages from Github. I thought I had everything set up correctly. The issue is referenced on Github in the commit; but it never closed the issue.

Unfortunately this is a private repo but this is screen shot of the commit message & reference in the issue:

By the conventions from the Github article closes acts as a keyword for carrying out the closing of the issue referenced. I'm wondering is it possible that when initializing a commit as a chore that this fails or is their possibly a configuration I am missing in the package.json?

{
  "scripts": {
    "commit": "git cz"
  },
  "devDependencies": {
    "commitizen": "^2.9.6",
    "cz-conventional-changelog": "2.0.0"
  },
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  }
}

the ability to ignore pre-release commits

Use Case: we are tagging every commit to master with a release candidate pre-release tag (e.g. 1.2.3-RC.4) . Right now, we run changelog and it makes a new version entry for every pre-release, which is nice for unreleased changes... however, during a normal release, I'd like to re-generate the changelog, have it ignore pre-release tags, and only generate a changelog of full releases.
All this would take is for there to be an argument like --ignore-pre-release which would just not check tags with a - in it, when looking back to the previous tag.