Some people mentioned JIRA

CC @rsids @bennekrouf @z0r1k

bitbucket is partially supported apparently.

Will be nice if would it supports mercurial(hg) as well.

It'd be really nice to have the ability to get JSON-formatted Changelogs. I realize the standard is .md, but having JSON output would help immensely in creating a view pertaining to all changes that end-users and binding the .json output as the data source and never have to worry about updating the view itself once the logic is in place.

Hey, I'd like to request a release because of 69cfb5c. The newest release is now 9 months old and some other fixes appeared in the master branch, too, so it could be a good time :).

Thanks!

Not sure if this is exactly the issue, but it was the only consistency I could see between the output in https://github.com/btford/grunt-conventional-changelog/blob/master/CHANGELOG.md and the commits.

Examples:

- changelog: cannot generate changelog for first tag () (706a284b, closes `#27`)
- allow 100 characters in commit message () (9982d897, closes `#28`)

Note the odd () in each of those messages before the commit SHA.

Clicking either of those SHAs in the grunt-conventional-changelog repo's CHANGELOG file gives you these two commits:

• btford/grunt-conventional-changelog@706a284

  fix(changelog): cannot generate changelog for first tag (Closes #27)

• btford/grunt-conventional-changelog@9982d89

  feat(validator): allow 100 characters in commit message (Closes #28)

Hi.

For some projects it makes sense to have issue number which are not just digits.
I.e. Jira issues like PRJ-1337.
It is not desirable to strip down "PRJ-" and prepend it again in issueLink function since other systems like Bamboo/Stash will not recognise issue reference.

Patch bellow can be used to fix this.
It adds additional configuration parameter issuePrefix.

From e05e5a1bc69de9a6a13c0fd6ab1b9996885f56c2 Mon Sep 17 00:00:00 2001
From: Mykhailo Lieibenson <[email protected]>
Date: Tue, 2 Dec 2014 00:01:54 +0100
Subject: [PATCH] feat(config): Adding issuePrefix configuration option

---
 index.js   |  1 +
 lib/git.js | 25 +++++++++++++++++++------
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/index.js b/index.js
index a5d02a4..c5e99f7 100644
--- a/index.js
+++ b/index.js
@@ -33,6 +33,7 @@ function generate(options, done) {
     git.getCommits({
       from: options.from,
       to: options.to,
+      issuePrefix: options.issuePrefix
     }, function(err, commits) {
       if (err) return done('Failed to read git log.\n'+err);
       writeLog(commits);
diff --git a/lib/git.js b/lib/git.js
index 6583cb4..91f00b0 100644
--- a/lib/git.js
+++ b/lib/git.js
@@ -73,25 +73,38 @@ function parseRawCommit(raw, options) {
   var lines = raw.split('\n');
   var msg = {}, match;

+  var prefix = options.issuePrefix || "";
+  prefix.replace("-", "\\-");
+
+  var parse = !prefix ? parseInt : function(val){ return val; }
+
   msg.hash = lines.shift();
   msg.subject = lines.shift();
   msg.closes = [];
   msg.breaks = [];

-  msg.subject = msg.subject.replace(/\s*(?:Closes|Fixes|Resolves)\s#(\d+)/ig, function(_, i) {
-    msg.closes.push(parseInt(i, 10));
-    return '';
-  });
+  msg.subject = msg.subject.replace(
+    new RegExp("\\s*(?:Closes|Fixes|Resolves)\\s#" + prefix + "(\\d+)", "ig"), function(_, i) {
+      msg.closes.push(parse(i, 10));
+      return '';
+    }
+  );

   lines.forEach(function(line) {
-    match = line.match(/(?:Closes|Fixes|Resolves)\s((?:#\d+(?:\,\s)?)+)/ig);
+    match = line.match(new RegExp("(?:Closes|Fixes|Resolves)\\s((?:#" + prefix + "\\d+(?:\\,\\s)?)+)", "ig"));

     match && match.forEach(function(m) {
       m && m.split(',').forEach(function(i) {
         var issue = i.match(/\d+/);
-        issue && msg.closes.push(parseInt(issue[0], 10));
+        issue && msg.closes.push(parse(issue[0], 10));
       });
     });
+
+    if (match) {
+      match[1].replace(/[\s#]/g, '').split(',').forEach(function(i) {
+        msg.closes.push(parse(i, 10));
+      });
+    }
   });

   match = raw.match(/BREAKING CHANGE:\s([\s\S]*)/);
-- 
2.2.0

Hi, I'm having an uncaught error when using the CLI.

Environment

• conventional-changelog@next
• Windows 7
• Node v0.12.5 & IOjs v2.3.2
• NPM v2.11.2 & v2.11.3

Is it Unix only maybe?

Repro

It happens when running either :

node ./node_modules/conventional-changelog/cli -i CHANGELOG.md -w -b
convetional-changelog -i CHANGELOG.md -w -b

with or without flags

Stack

Here's the stack :

events.js:87
      throw Error('Uncaught, unspecified "error" event.');
            ^
Error: Uncaught, unspecified "error" event.
    at Error (native)
    at Readable.emit (events.js:87:13)
    at Readable.<anonymous> (.\node_modules\conventional-changelog\index.js:144:20)
    at Readable.emit (events.js:107:17)
    at DestroyableTransform._transform (.\node_modules\conventional-changelog\node_modules\git-raw-commits\index.js:48:16)
    at DestroyableTransform.Transform._read (.\node_modules\conventional-changelog\node_modules\through2\node_modules\readable-stream\lib\_stream_transform.js:172:10)
    at DestroyableTransform.Transform._write (.\node_modules\conventional-changelog\node_modules\through2\node_modules\readable-stream\lib\_stream_transform.js:160:12)
    at doWrite (.\node_modules\conventional-changelog\node_modules\through2\node_modules\readable-stream\lib\_stream_writable.js:323:12)
    at writeOrBuffer (.\node_modules\conventional-changelog\node_modules\through2\node_modules\readable-stream\lib\_stream_writable.js:309:5)
    at DestroyableTransform.Writable.write (.\node_modules\conventional-changelog\node_modules\through2\node_modules\readable-stream\lib\_stream_writable.js:236:11)

When handling Readable's errors :

I've tried handling the readable's errors with :

readable.on('error', function(err) {
    console.log(err);
});

It's removed the Uncaught Error and printed

Error in git-raw-commits. fatal: unrecognized argument: ------------------------'

I've also printed the options passed to gitRawCommits :

{
    format: '%B%n-hash-%n%H%n-gitTags-%n%d%n-committerDate-%n%ci',
    from: 'v2.0.0'
}

Git Log

Here's my git log if it can help :

feat: try to trigger changelog
docs: update changelog generation
docs: update changelog
docs: clean generated changelog
docs: update changelog
v2.0.0
feat(npm): add scripts
feat: add changelog
fix: README
fix: README
feat: add Travis CI
feat: add linting
feat: add defaults template values
style: clarify function's name
style: use private variables, setters and getters
style: add new lines, semi-colons and move variables
chore: v1.6.0
fix: return object when the result is an object and not a9f931e2e10acf4108574cff365274d80819bbb3b chore: v1.5.0
feat: add `langs` to list all available languages
fix(has): check for the language before the key
chore: v1.4.0
test: add tests
fix: use default `lng` in `has` function
fix: return `key` if inexistant
fix: use default object if `data` isn't provided
chore: change `string` to `dico`
chore: v1.3.0
docs(get): update docs with new feature for overwrite
feat(get): add the possibility to overwrite language
chore: v1.2.0
docs: update docs with `has` and other small adjustements
feat: add `has` function to check on availability of loca
chore: add badges to readme
v1.1.0
fix: update commonjs and amd support
v1.0.1
chore: update readme
chore: format readme
docs: add documentation
feat: change `t` to `get`
chore: typo in readme
feat: npm support
feat: bower support
feat: add lib
Initial commit

Thanks for your awesome tool anyway.

#52

In the up coming new release we can fully customise the commit message format so a strict commit message guideline is not necessary.

My team would like to use these conventions but spell out the entire word "feature" in our commit messages.

There is a link at the end of the CONVENTIONS.md that links to a document that doesn't exist.

A detailed explanation can be found in this document.

Hi !

Im trying to set up a new workflow for a new project Im working at. I really would like to use conventional-changelog, but for the moment is being impossible to me to make it work.

First of all, I cant even make the cli tool working. I did installed globally, but each time Im trying to run:
conventional-changelog --help on the shell, it said: conventional-changelog: command not found, but if I make npm ls -g -depth=0 I can see [email protected] package listed.

Another issue Im having is that I cant create the changelog.

I have already some commits (indeed only one) on the angular format. Its like this:

feat(): onUrlChange event (popstate/hashchange/polling) (this is an example copied from the docs, for debugging)

I also have a CHANGELOG.md empty file on the root and I have created a test.js with the following:

var conventionalChangelog = require('conventional-changelog');

conventionalChangelog({
  preset: 'angular'
})
  .pipe(process.stdout);

Whenever run node test I get :

conventionalChangelog().pipe(process.stdout);
                       ^
TypeError: Cannot read property 'pipe' of undefined
    at Object.<anonymous> (/Users/antonio/Projects/cabesa/test.js:45:24)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:501:10)
    at startup (node.js:129:16)
    at node.js:814:3

Any suggestion to put me on the right spot ?

My final goal will be to create some gulp tasks that manage all process automatically: deploying, documentation, testing, etc... but Im stuck here.

Thanks

Hi there,

Trying to get alpha 3 to work and at the moment although I can get a bare changelog produced, a commit message like:

feat(blah): my message

Comes out as

### feat

* feat(blah): my message

Looking at the docs and the tests, I was expecting:

### New features

* blah: My message

We use convential-changelog in generator-angular and we would like to switch from a changelog.md file to GitHub Releases.

There's an API so should be possible to automate it:
http://developer.github.com/v3/repos/releases/

See discussion clog-tool/clog-cli#10 (comment)

Hi, I think there is an issue with the last version on this task. If you have a project without tags and some commits, when you try to execute the task, the console shows "Generating changelog from undefined to undefined".

However, if you have a tag or you use the versión 0.0.11 the task works. Maybe the problem is related with the else in the getFirstCommit function, because if the repository has commits executes this line: done(null, ''); (with the second parameter empty).

The versión 0.0.11 uses this line instead:

done(null, String(stdout).split('\n')[0].split(' ')[0].trim());

Regards.

It should be an option to set from previous how many semver tag and generate how many versions.

options.versionRange = {
    start: -1, // Index of semver tags at which to start. If greater than the number of existing semver tags, actual starting index will be set to the number of the tags. If negative, it will begin that many from the end. If a absolute negative number is greater than the number of existing semver tags or 0, it is 1.
    count: 1 // How many versions to generate.
}

This is much better than allBlocks 😄 please suggest better option name.

Running grunt release on karma, produced this Changelog: https://github.com/karma-runner/karma/blob/master/CHANGELOG.md#0137-2015-08-05 which includes the two items from the previous release. Any ideas what's going on?

npm allows users to specify repository as 'npm/npm' - when there is no htttp:// nor git:// in url it assumes github. The address is created by github-url-from-username-repo. Currently this format is not understood properly by conventional-changelog. This format is not very pupular but at least in generator-angular it caused issues.

I will try to prepare PR in the free time.

some fields default to the values in package.json

#43 But I want to have more features. Eg: auto bump based on #29.

I have been stressed to see 404, when I was opening conventions cheat sheet to choose commit type for commit. Where I can find them now?

404 link is https://github.com/ajoslin/conventional-changelog/blob/master/CONVENTIONS.md#type

I am using Stash which uses 4 spaces for Nested Lists instead of the 2 that Github uses. It would be nice to have the ability to change how many spaces are used for nested lists.

Currently, this plugin only supports numeric issues. When using Jira, issues are (possibly) prefixed with non numeric characters (e.g. PROJECT-123). When adding a comment like 'Closes PROJECT-123', these lines are not appended in the changelog, because it expects a hash, followed by a number.

How about exposing the grep(ref) option, this way you can set which conventions you want in the changelog. The additional commits with conventions that don't match Fix, Feature, Breaking would be grouped as "Other fixes" in the changelog.

Thoughts?

Whats the reason for not writing the change log into a the file but returning it as a string. I expected that it would write into the file in the first place. After thinking about it I can see reasons for just returning the string but then I would expect that it would only return the last changes not the whole change log, cause this can be done by the user if needed.

Does this include pull requests? Currently I'm running it against my project but am seeing 0 commits -- however we've contributed dozens of PRs since the last release, but no direct commits. Does this mean this only reads direct commits? Is there a way to turn on PRs?

In our package.json, we're using the shorthand format for the repository field, "mozilla/fxa-content-server". We noticed that when generating the changelog (via grunt-conventional-changelog) that the links in the CHANGELOG.md don't resolve properly:

Using shorthand in the package.json:

"repository": "mozilla/fxa-content-server",

Generates this:

<a name="0.33.0"></a>
## 0.33.0 (2015-03-23)


#### Bug Fixes

* **test:** Fix the account locked tests when run against latest. ([45073cf6](mozilla/fxa-content-server/commit/45073cf66cf69118251c85846f6ce0e330f8bafd))


#### Features

* **client:** Add the account locked flows. ([8e405298](mozilla/fxa-content-server/commit/8e405298b8fee3b1e5c4e495a006d42580432c49))

If we switch to the long version of repository:

  "repository": {
    "type": "git",
    "url": "https://github.com/mozilla/fxa-content-server"
  },

We get this (fully qualified URLs):

<a name="0.33.0"></a>
## 0.33.0 (2015-03-23)


#### Bug Fixes

* **test:** Fix the account locked tests when run against latest. ([45073cf6](https://github.com/mozilla/fxa-content-server/commit/45073cf66cf69118251c85846f6ce0e330f8bafd))


#### Features

* **client:** Add the account locked flows. ([8e405298](https://github.com/mozilla/fxa-content-server/commit/8e405298b8fee3b1e5c4e495a006d42580432c49))

Similarly, if you use a repository url of git:// then it isn't convertingand parsing correctly:

  "repository": {
    "type": "git",
    "url": "[email protected]:mozilla/fxa-content-server.git"
  },

Then it generates links like this:

<a name="0.33.0"></a>
## 0.33.0 (2015-03-23)


#### Bug Fixes

* **test:** Fix the account locked tests when run against latest. ([45073cf6]([email protected]:mozilla/fxa-content-server/commit/45073cf66cf69118251c85846f6ce0e330f8bafd))


#### Features

* **client:** Add the account locked flows. ([8e405298]([email protected]:mozilla/fxa-content-server/commit/8e405298b8fee3b1e5c4e495a006d42580432c49))

Long story longer, it doesn't look like we're normalizing the Git URLs everywhere and assuming that the repository URL is HTTP-esque.

Currently it is not clear form the document what parts (scope, body, footer) are optional and what parts are required.

I think it would make sense to clarify this.

hi, if you execute the command inside function latestTag under Windows shell (not the Git shell) throws an error unknow option max-count=1 due to backtick.

I have made a quick test by making two calls instead of only one, using the output of a command to pass to the other one. With this change, it finds the tag.

Hi,
First of all, thanks for this great tool 👍
I would like to be able to configure the regexp headerPattern a bit to allow these variations:

<type>(<scope>): <subject>

 <type>(<scope>) : <subject>

 <type>(<scope>) <subject>

Thanks

When I generate using "allBlocks" option, I get a changelog that holds everyting from the from to HEAD and uses just the latest version information from the package.json as the header for everything it found the logs.

I need to rebuild my log on every build, so I would like to have all the GIT-tags I set taken into account when generating the log.

My options:

{
    // Task-specific options go here.
    from : '1.0.0',
    allBlocks: true
}

The issue occurs on line 88 of index.js. getPkgRepo fails if there is no repository information, which prevents the version information from being added to the context object, causing blank values in the changelog output.

I'll see if I can get a PR out for this.

Steps to recreate:

1. Have an NPM repository without a repository field:

{
  "name": "my-package",
  "version": "1.0.1",
}

1. Run conventional-changelog
2. See that output does not pick up version information

I've been working with conventional-changelog over the past two days and ran into some behavior that seemed odd. I'm not sure if it's an issue or not but since the version I'm using is the latest beta I thought I'd report it in case it is an issue or in case I'm doing something wrong.

I'm using conventional-changelog@^0.1.0-beta.3 on Mac OS X 10.10.4 with Node.js v0.12.4. I'm able to generate CHANGELOG.md using the following code but only under certain conditions.

conventional-changelog -o CHANGELOG.md -p angular -v

Scenario 1:
If I have conventional-changelog installed as a global npm module the code works. If it's installed as a local npm module I get the following error:

-bash: conventional-changelog: command not found

This could be an issue with something I'm doing. Or not doing.

Scenario 2:
If I have created a tag with git tag -a v0.0.1 -m "Initial testing release." the code above doesn't work. A changelog file is created but it's blank/empty. If I delete the git tag and rerun conventional-changelog, a changelog is generated and has content as expected.

Thanks for the work on this tool. Our engineering team is looking at using it to help us with better process and better documentation right from our commit logs.

When we create a release on our project, we want to include all the changes (bug fixes, features, breaking changes) in the github release notes. However, in our changelog we only want to include the breaking changes.

It would be nice if there was a option that we could pass in to configure this. I.e.

changelog({
  ...
  changeLevels: ['features', 'breaking']
}, function(err, log) {
  ...
});

This would only include new features and breaking changes. If the argument isn't supplied, it defaults to all types.

Would you be open to a PR?

@gpleiss, @bebepeng @stubbornella, @DrPep

I'd like to update the regex that's used in parseRawCommit() in git.js.

I have a few commits that aren't being added to changelog that aren't being detected because they're formatted as such:

fix(category:subcategory): My subject

I've updated locally for myself, here's the regex that I've added:

var COMMIT_PATTERN = /^(\w*)(\(([\w\:\$\.\-\*]*)\))?\: (.*)$/;

I can't think of any downside if I do so.

Not sure what causes this yet. Maybe handlebars.js escapes it?

This is a natural extension of the library. This way we can install tool globally and use it for all sorts of projects.

I want to PR myself but I'm kinda squeezed atm. Will notify if I decide to. Thanks again!

I would like to be able to use a custom commit pattern. It would be nice to have an option to customize the following regex:

var COMMIT_PATTERN = /^(\w*)(\(([\w\$\.\-\* ]*)\))?\: (.*)$/;

And also I would like to be able to list more than just feat & fix commits in the changelog (docs for example, and probably other things later), it would be nice to be able to provide a list of the headers to parse.

If you don't have the time to do it but think it's a good idea, just tell me and I'll work on it and send a PR.

Bitbucket commit URL contains "commits" instead of "commit". So the issues URL references are broken link in the generated change log file.

More generally, how do we do when commit and issue repositories are different.
In my case I have :

• issues in : https://company.jira/browse
• commits : https://bitbucket.org/company/commits/

In my package.json I have :

"bugs": { // standard package.json field
"url" : "https://company/browse"
, "email" : "[email protected]"
},
"commits": "https://bitbucket.org/company/commits/" // Custom field

It would be convenient to be able to specify those parameters

conventionalChangelog({
repository: repository.url,
issues: bugs.url,
commits: commits,
...
})

Arguably no release should take place where there are no functional changes from the user point of view (feat, fix) but it might happen that such a release is done nevertheless... In such a case a generated log looks a bit bizarre, here is an example:
https://github.com/karma-runner/karma/blob/master/CHANGELOG.md#v0126-2014-04-09

Maybe adding a small comment, sth like:

_There are no functional changes in this release, only documentation updates, refactorings, [list type of changes here] _

@ajoslin WDYT?

Previous discussion #82 and #53 but please keep this discussion of the topic in this thread.

Since this module will return a stream, we should let wrapper modules to deal with how they want to handle logs (prepend or append texts etc...) and let this module focus on generating logs.

eg in bash we could do

changelog --from 277ebe3a68fd1e72cf7ed15c2b605b847dd3c683 >> CHANGELOG.md

there is a spelling problem in index.js

var rhosts = /github|butbucket/i;

it's bitbucket, not butbucket

This is for testing.

I could do something like

if (process.env.test)
...

But I wonder if we can swap the actual 'child_process' package with my dodge package when testing.

per angular/angular.js#12032 (comment)

Not sure if this should go to the parser or writer

@ajoslin I'm working on several build-related topics atm and can see number of use-cases where I could use just the git-related part, ex.:

• figure out next semver based on the commit names
• use completely different writing format / target (I think GH releases were mentioned).

In short: IMO splitting up the repo into 2 distinct parts would make each part more useful and easier to maintain. The interface between 2 parts would be output generated by git parsing.

I can surely just require lib/git.js from this repo (might break without warning) or just fork the whole thing (not so great for the community / ecosystem) but yeh, I feel like the sum of parts could be greater than the combined thing. WDYT? I know you are busy on other topics but I will need this type of think so willing to put some effort into it.

We should make our option defaults all be set in index.js, if possible. It's getting too scattered and confusing (all the files except Writer.js change the options)