conventional-changelog-archived-repos / conventional-commits-parser Goto Github PK

EG: # or gh-

would be good if it also supports "Closing an issue in a different repository"

Reference:

• https://help.github.com/articles/closing-issues-via-commit-messages/
• https://help.github.com/articles/writing-on-github/#references

looks like a trailing newline is troublesome :(

Mention someone in the commit message.

I suggest that if you want to catch BREAKING CHANGE, you probably also want to catch Breaking Change and Breaking change. It's tricky for individual conventional-chagelog-* to do this since they can't change the regexp options. Could this be the default, or if that's considered a dangerous breaking change, could there be an option to make them case insensitive?

Currently, only issues prefixed with a # or a GH- are recognised as an issue. When using an issue tracker like JIRA, issues can have all sorts of prefixes. My suggestion is to make the prefix configurable, so you can set it like this:
issuePrefix: ["BB-", "PROJECT-", "WHATEVER-"]

For enterprise projects using Jira/Bitbucket Server, the # symbol doesn't really apply the way it does in Github. A regex would allow developers to use something like /[A-Z]+\-[0-9]+/, which would capture any Jira issue key. Is there already some way of doing this, or would this approach fit with your plans for the library?

My current solution is providing an array of Jira project names, and using the raw value in the commit template, but the static list approach might get unwieldy.

the following commit message:

fix: upgraded dependencies, switched back to angular format (fixes #27), pinned shelljs to version that works with nyc (#30)

results in a corrupt commit entry:

* upgraded dependencies, switched back to angular format (fixes [#27](https://github.com/conventional-changelog/standard-version/issues/27)), pinned shelljs to version that works with nyc ([#30](https://github.com/conventional-changelog/standard-version/issues/30))([3f51e94](https://github.com/conventional-changelog/standard-version/commit/3f51e94)), closes [#27](https://github.com/conventional-changelog/standard-version/issues/27) [(#30](https://github.com/(/issues/30)

the underlying cause seems to be the way references (fixes #foo are handled).

Currently all \n\n or more \ns will be parsed as \n.
karma-runner/karma#1562

Not sure if we need to trim \n between different parts

Users should be able to define which capturing group captures what.

commit header like 'README(feat): whatever' will be parsed properly.

• should ends with 1 if it errors
• should use isTTY to check what to do with stdin

conventional-changelog-archived-repos/conventional-changelog-angular#9

And let headerCorrespondence define the order and the names 😄

repo owner

Better name

Hi Steve,

Wasn't sure where to put this or how I could reach out to you other than Github so please close as needed.

I think the conventional commit format is great but IMO there is a missing piece right now for people who just want to make commits to a repo without remembering the exact formatting spec that a repo author prefers. Sometimes I want to commit to a repo and there is a specific format that the repo author prefers. This is great but ideally I, as the contributor, would prefer to be prompted for the required commit message fields rather than having to remember the convention of every repo. It also isn't helpful for ides or scm tools that might want to change their behavior based on a repo's preferred commit format.

Git pre-commit hooks are great for stopping me, the one-off contributor, from doing harm, but from a tooling perspective they leave something to be desired because they don't actively prompt me for the require commit fields using something like inquirer.

So I wanted to get your pulse on this so see if you think it would be possible or even preferable to have some sort of config file that repo authors could include in the repo that defines certain norms when it comes to commit messages.

Since you're writing the updated parser and writer for changelog, I figured it was worth checking in. I haven't worked out the details yet but my guess is that it would be something like .commitformat or .commitconvention

Any overlap between this and what you're working on?

Thoughts.

I created a merge request on GitLab, leaving the title of the merge request as the default (the header line of my commit). Therefore it was Docs/readme.

Upon accepting the merge request I ended up with a merge commit in my history that looks like:

commit ccc375b33f12355db58d5af81d63ab84e843ab59
Merge: 594e972 aaf372a
Author: Hutson Betts <[email protected]>
Date:   Sun Aug 7 03:23:26 2016 +0000

    Merge branch 'docs/readme' into 'master'

    Docs/readme



    See merge request !1

When running the commit through conventional-commits-parser I end up with the following commit object:

{ type: null,
  scope: null,
  subject: null,
  merge: null,
  header: 'Merge branch \'docs/readme\' into \'master\'',
  body: 'Docs/readme\n\n\n\nSee merge request !1',
  footer: null,
  notes: [],
  references: [],
  mentions: [],
  revert: null }

It seems the line containing !1 is not parsed out.

I changed issuePrefix to include !, but since the merge request ID is not part of the footer, I can't get the merge request ID as an issue reference.