npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

git-release-notes

v5.0.0

Published

Generate beautiful release notes from a git log.

Downloads

6,861

Readme

Release Notes

Generate release note pages from git commit history.

Installation

It's preferable to install it globally through npm

npm install -g git-release-notes

It's also possible to use git-release-notes as a node module. Check the usage on usage as a module

Usage

The basic usage from the command line is

cd <your_git_project>
git-release-notes <since>..<until> <template>

Where

  • <since>..<until> specifies the range of commits as in git log, see gitrevisions(7)
  • <template> is an ejs template file used to generate the release notes

Three sample templates are included as a reference in the templates folder

This for example is the release notes generated for joyent/node by running

git-release-notes v0.9.8..v0.9.9 html > changelog.html

Custom template

The second parameter of git-release-notes can be any path to a valid ejs template files.

Template Variables

Several template variables are made available to the script running inside the template.

commits is an array of commits, each containing

  • sha1 commit hash (%H)
  • authorName author name (%an)
  • authorEmail author email (%ae)
  • authorDate author date (%aD)
  • committerName committer name (%cn)
  • committerEmail committer email (%ce)
  • committerDate committer date (%cD)
  • title subject (%s)
  • tag tag (%D)
  • messageLines array of body lines (%b)

dateFnsFormat is the date-fns format function. See the html-bootstrap for sample usage.

range is the commits range as passed to the command line

Options

More advanced options are

  • p or path Git project path, defaults to the current working path
  • b or branch Git branch, defaults to master
  • t or title Regular expression to parse the commit title (see next chapter)
  • i or ignore-case Ignore case flag for title's regular expression. /.*/ becomes /.*/i
  • m or meaning Meaning of capturing block in title's regular expression
  • f or file JSON Configuration file, better option when you don't want to pass all parameters to the command line, for an example see options.json
  • s or script External script for post-processing commits
  • c or merge-commits List only merge commits, git log command is executed with the --merges flag instead of --no-merges
  • o or gitlog-option to add some additional git log options and ignores the merge-commits option, this is direct given to git log by adding a -- to each longname option from the array (e.g. -o first-parent).

Title Parsing

Some projects might have special naming conventions for the commit title.

The options t and m allow to specify this logic and extract additional information from the title.

For instance, Aria Templates has the following convention

fix #123 Title of a bug fix commit
feat #234 Title of a cool new feature

In this case using

git-release-notes -t "^([a-z]+) #(\d+) (.*)$" -m type -m issue -m title v1.3.6..HEAD html

generates the additional fields on the commit object

  • type first capturing block
  • issue second capturing block
  • title third capturing block (redefines the title)

Another project using similar conventions is AngularJs, commit message conventions.

git-release-notes -t "^(\w*)(?:\(([\w\$\.]*)\))?\: (.*)$" -m type -m scope -m title v1.1.2..v1.1.3 markdown

Post Processing

The advanced options cover the most basic use cases, however sometimes you might need some additional processing, for instance to get commit metadata from external sources (Jira, GitHub, Waffle...)

Using -s script_file.js you can invoke any arbitrary node script with the following signature:

module.exports = function(data, callback) {
  /**
   * Here `data` contains exactly the same values your template will normally receive. e.g.
   *
   * {
   *   commits: [], // the array of commits as described above
   *   range: '<since>..<until>',
   *   dateFnsFormat: function () {},
   *   debug: function() {}, // utility function to log debug messages
   * }
   *
   * Do all the processing you need and when ready call the callback passing the new data structure
   */
  callback({
    commits: data.commits.map(doSomething),
    extra: { additional: 'data' },
  });
  //
};

The object passed to the callback will be merged with the input data and passed back to the template.

For an example check samples/post-processing.js

Usage as a module

Installation

npm install --save-dev git-release-notes

Usage

Inside your script file

const releaseNotes = require('git-release-notes');

const OPTIONS = {
  branch: 'master',
};
const RANGE = 'v1.0.0..v2.0.0';
const TEMPLATE = 'markdown';

releaseNotes(OPTIONS, RANGE, TEMPLATE)
.then((changelog) => {
  console.log(`Changelog between ${RANGE}\n\n${changelog}`);
})
.catch((ex) => {
  console.error(ex);
  process.exit(1);
});

Options

The syntax reflects the command line parameters, so options is an object containing path, branch, title and so on. You can refer to the list of options in the command line usage section. You can use either the long or short syntax, the module will use the same defaults as the command line if an option is missing.

However, there is a little difference between module usage and CLI of the script parameter. When used as CLI, it receives a path link to a JS module file, but used as a module, it receives a function:

releaseNotes({
  branch: 'master',
  script: (data, callback) => {
    callback({
      foo: 'bar'
    })
  }
}, RANGE, TEMPLATE)

Typescript

git-release-notes includes Typescript definitions.

import * as releaseNotes from "git-release-notes";
releaseNotes({ path }, range, TEMPLATE);

Debug

If your post processing script or template throws an exception, the JSON data will be written to the file system in the same folder as the processing script.

The DEBUG environment variable can also be useful for fault diagnosis:

Linux

export DEBUG=release-notes:*
git-release-notes ...

Windows

SET DEBUG=release-notes:cli,release-notes:externalscript
git-release-notes ...