conventional-changelog / commitlint

📓 Lint commit messages

Conventional Changelog

Generate a CHANGELOG from git metadata.

About this Repo

The conventional-changelog repo is managed as a monorepo; it's composed of many npm packages.

The original conventional-changelog/conventional-changelog API repo can be found in packages/conventional-changelog.

Getting started

It's recommended you use the high level commit-and-tag-version library, which is a drop-in replacement for npm's version command, handling automated version bumping, tagging and CHANGELOG generation.

Alternatively, if you'd like to move towards completely automating your release process as an output from CI/CD, consider using semantic-release.

You can also use one of the plugins if you are already using the tool:

Plugins Supporting Conventional Changelog

• grunt
• gulp
• atom
• vscode
• emacs

Modules Important to Conventional Changelog Ecosystem

• conventional-changelog-cli - the full-featured command line interface
• standard-changelog - command line interface for the angular commit format.
• conventional-github-releaser - Make a new GitHub release from git metadata
• conventional-recommended-bump - Get a recommended version bump based on conventional commits
• conventional-commits-detector - Detect what commit message convention your repository is using
• commitizen - Simple commit conventions for internet citizens.
• commitlint - Lint commit messages

Node Support Policy

We only support Long-Term Support versions of Node.

We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment.

It's possible this package will work correctly on newer versions of Node. It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.

As each Node LTS version reaches its end-of-life we will remove that version from the node engines property of our package's package.json file. Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package. We will not accept any requests to support an end-of-life version of Node. Any merge requests or issues supporting an end-of-life version of Node will be closed.

We will accept code that allows this package to run on newer, non-LTS, versions of Node. Furthermore, we will attempt to ensure our own changes work on the latest version of Node. To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.

JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property. If you encounter issues installing this package, please report the issue to your package manager.

commitlint's Issues

support skipping linting

with the transition from validate-commit-msg to commitlint, one missing feature that i notice is the ability specify that a commit should skip linting by including a keyword in the message. i initially asked if this would be added in the thread about the transition, but was righty directed here to open an issue.

in the case of validate-commit-msg, the keyword was simply starting the commit message with WIP, which has worked well for us when a commit is a step toward one of the categories, but does not complete the effort.

would it be possible to support similar functionality in commitlint to save us from needing to configure some sort of wrapper in all of our projects?

Allow to configure commintlint in package.json or with json/yaml file

It would be convenient to allow commitlint to be configured within package.json or with a json or yaml file, similarly to eslint, prettier, stylelint etc...

cosmiconfig allow to do that pretty easily (as a replacement of rc).

Would you be open to such PR ?

bump version from npm

npm version 0.1.8

npm ERR! code 1
npm ERR! Command failed: git commit -m 0.1.8
npm ERR! husky > npm run -s commitmsg (node v8.4.0)
npm ERR! 
npm ERR! ⧗   input: 0.1.8
npm ERR! ✖   message may not be empty [subject-empty]
npm ERR! ✖   type may not be empty [type-empty]
npm ERR! ✖   found 2 problems, 0 warnings
npm ERR! 
npm ERR! husky > commit-msg hook failed (add --no-verify to bypass)

Idea: Build a serverless gitcop alternative

Reference: https://gitcop.com/home

Idea: Build a package that allows fast and painless setup of a serverless gitcop alternative.

• Build as integrated with Github as possible
• Try to tackle the squash problem

How to lint all commits in a PR?

I'd like to integrate conventional-changelog-lint into my CI process. I can enforce a commit convention on "client side" using Husky as per docs, but how would I enforce the convention on CI?

Assuming that a PR is a list of commits that do not exist on master, then getting those commits is simple:

git log master..$(git symbolic-ref --short HEAD)

I am not sure though whats the best way to feed them to conventional-changelog-lint. Here is what I have ended up with for now:

for sha in $(git --no-pager rev-list master..$(git symbolic-ref --short HEAD)); do git cat-file commit $sha | sed '1,/^$/d' | conventional-changelog-lint; done

The problem with the latter is that it doesn't exit if either of the validation fails.

Consider picking up changelogrc files

See

• https://github.com/Jimdo/changelogrc-spec
• conventional-changelog/conventional-changelog#146

.changelogrc and package.json[changelog] could serve as config picked up by a whole family of tools, conventional-changelog-lint merely being one of them.

This would involve

• working with https://github.com/Jimdo/changelogrc-spec to extend the spec
  • with more configuration keys
  • with a wildcard extensible object carrying tool-specific configuration
  • with a notion of being located in package.json, think like ava, xo
• deprecating .conventional-changelog-lintrc

throws error on "build(npm): update dependencies" ?

hi,

⧗   input: build(npm): update dependencies
✖   type must be one of ["chore", "docs", "feat", "fix", "perf", "refactor", "style", "test"] [type-enum]
✖   found 1 problems, 0 warnings

executed vi npm script in node-developer-boilerplate with string build(npm): update dependencies

Angular 1x Convention - old without build and ci
Angular 2x Convention - added build + ci
Commitizen conventional-commit-types - added build + ci

did you forgot to add it?

cheers maik

prompt: Skip optional fields on empty submit

From @fahrradflucht

It would be great if one wouldn't have to write :skip every time to submit optional fields. I think submitting an empty input field should be enough to skip a section.

prompt-cli: check stage before entering prompt

@commitlint/prompt-cli fails for empty git stages after authoring the commit message. This makes for a frustrating experience.

Check if there are files in stage before entering the prompt.

---

Edit

The implementation for this should happen before this line: @commitlint/prompt-cli/cli.js#L21

main could look like this:

async function main() {
  if (await isStageEmpty())  {
    console.log(`Nothing to commit. Stage your changes via "git add" execute "commit" again`);
    process.exit(1);
  }

  return prompt();
}

async function isStageEmpty() {
   const result = await execa('git', ['diff', '--cached']);
   return result.stdout === '';
}

Make first-time encounters easier for contributors

First time contributors of projects using commitlint run into our checks unprepared.

This increases friction at a point critical for every OSS project, up to the point where commit messages are lost:

• remy/nodemon#1110 (comment)
• googleapis/cloud-trace-nodejs#543
• google/gts#8
• uPortal-Attic/uportal-app-framework#535

We should do more to make contributing as easy as possible when commitlint is used

1. @commitlint/template. Will prepend commit messages with example messages generated from our config. Idea snatched from remy/nodemon#1110 (comment), example: lennym/commit-template. This introduces a second husky commit hook, increasing install complexity. Decide if commitlint init should set this when implemented: https://github.com/marionebl/commitlint/issues/48

2. commitlint restore: Let users restore commit messages that failed the tests for repeated edits. Theoretically we could even create a preparecommitmsg hook to read that from an agreed-upon place?

3. commitlintbot: Support commitlintbot to become the go-to tool for projects opting for linting on PR/Squashing level only. This approach moves the burden of commit conventions to project maintainers entirely.

Message Commit hook doesn't work with git gui

Using the recommended husky commit message hook doesn't work with git gui.

 {
    "scripts": {
      "commitmsg": "conventional-changelog-lint -e"
    }
  }

The issue is that -e assumes the commit message is at .git/COMMIT_EDITMSG which is not always true.
git gui for example places the commit message at .git/GITGUI_EDITMESSAGE.
Looking at the sample commit-msg hook from Git it specifies that the location of the file containing the commit message is passed as first argument $1.

To make this work I think there are two changes necessary:

1. make -e accept an argument
2. change the husky hook to "commitmsg": "conventional-changelog-lint -e $GIT_PARAMS"

Point two is required as husky doesn't pass the arguments directly but instead puts them into an environment variable GIT_PARAMS.

Removing explicit preset naming convention or add option to configure without

I'm trying to use cz-conventional-changelog as my preset but am unable to because of the hard coded conventional-changelog string. Is there a way to work around this? If not would you consider simply removing the hard coded string?

https://github.com/marionebl/conventional-changelog-lint/blob/master/source/library/get-preset.js#L2

export default async name => {
	return await require(`conventional-changelog-${name}`);
};

cli: Provide an init command

As seen in #47 setup currently easily allows for errors in documentation and frustration for users. Add an commitlint init [--extends] command. It should

• create a new commitlint.config.js file if needed, prefer package.json if available

• ensure @commitlint/cli

  • install/update @commitlint/cli as needed

• add configs provided via --extends to module.exports.extends

  • default to @commitlint/config-conventional
  • support multiple --extends
  • check if values are available if npm ids
  • install/update @commitlint/config-* as needed
  • disable via --no-config

• ensure husky

  • ensure presence of commitmsg run-script
  • disable via --no-husky

• add @commitlint/travis-cli to .travis.yml if file is found and not in scripts

  • install/update @commitlint/travis-cli as needed
  • disable via --no-travis

• optional: respect .editorconfig? overkill

import-from is devdependcy?

I get the message "module import-from not found". Perhaps it should be a dependency instead of devdependency

type-enum fills in with angular values even when a lintrc file is included

Hi, I have a lintrc file that includes 7 values for type-enum. When I write a commit that fails that check, the list of possible type-enums includes 3 values from the angular config: 'revert', 'style' and 'test'.

my lintrc rule looks like this:

"type-enum": [ 2, "always", [ "Fix", "New", "Breaking", "Docs", "Build", "Upgrade", "Chore", "Update" ] ],

and I'm using husky in my package.json with "commitmsg": "conventional-changelog-lint -e",

this is my terminal output when I fail that check:
type must be one of ["Fix", "New", "Breaking", "Docs", "Build", "Upgrade", "Chore", "Update", "revert", "style", "test"] [type-enum]

Thanks for making this library!

Ignore Comment

Hey everyone, I'm using the awesome tool but I have one question.

Using this commit message:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
#       new file:   text.commit
#
#

I got:

⚠   tense of body must be present-imperative. Verbs in other tenses: starting - present-participle [body-tense]

Is possible ignore commit comments in commitlint?

Thanks in advance!

prompt: reimplement with ink

The current implementation of @commitlint/prompt is tied to vorpal.

While vorpal provides great UX in a lot of ways it limits the adaptability of @commitlint/prompt in important ways, e.g. #46, #63.

--cwd not working

from directory without commitlint config files, lets suppose home (~)

 ~  echo "foo" | commitlint --cwd /home/bjorn/.config/dotfiles/commitlint/
⧗   input: foo
✔   found 0 problems, 0 warnings

expected some error

 ~/.config/dotfiles/commitlint   master ●  tree -a.
├── .commintlint.json
├── node_modules
│   ├── conventional-changelog-lint-config-canonical
│   │   ├── conventional-changelog-lintrc.json
│   │   ├── index.js
│   │   ├── LICENSE
│   │   ├── .npmignore
│   │   ├── package.json
│   │   └── README.md
│   └── .yarn-integrity
├── package.json
└── yarn.lock

2 directories, 10 files

.commitlint.json

{
  "extends": ["canonical"]
}

P.S. what I want is to fallback on my personal .commintlint.json if current direcory has no .commintlint.json

Add test setup

Add an ava based test setup. While not giving coverage to the project right away it allows to add tests for fixed bugs and work on improved coverage in the future.

Rename project to a more generic name

The current project name (conventional-changelog-lint) implies that this tool is designed to be used with conventional-changelog. Regardless of whether thats true or not, the tool itself has potential for broader applications.

A good name would be something like commitlint.

Add Ignore Tense Rule/Feature

Moving from discussion in #13...

It would be great if there was a way to ignore tense for certain patterns (e.g. with a regex).

For example, I have a package name that ends with -fetching and, when I mention that package in a commit subject, this tool throws a warning. Arguably I should maybe rename that package, but I could definitely see this being useful in a variety of cases.

Not sure if this makes sense as a rule or something else, but I think it would definitely be a nice addition.

It's not clear which versions of node are supported

I couldn't find in docs which versions of node are supported. I want to use this tool on a library, which supports 0.10, 0.12, 4 and 6. It seems the linter consistently crashes on 0.10 and 0.12, so I'll have to run it conditionally in my CI.

(I know 0.10 and 0.12 versions should be doomed already, but still - what rocket science this linter uses that it can't run on those?)

It's not clear from any docs here whether crashing on 0.10 and 0.12 is a bug or feature.

Signed-off-by error

I've identified an error when using the signed-off-by key, when git commit --amend --no-edit or git commit --amend with or without the --signoff option is being used, following git commit --signoff event. Haven't had a chance to look at it yet but it is a little odd since it is part of the commit message itself...

[yarn] Wrong version of @commitlint/core (3.1.0 instead of 3.0.4) is installed by default

Description

As of yarn v0.27.5 it seems that yarn install checks for the latest compatible semver number when deciding which package version to install, ignoring the latest tag (probably for performance reasons). This means that yarn add @commitlint/cli installs dependency @commitlint/[email protected] by default.

This is not an issue when using npm.

Solution

Bumping the global lerna version to 3.1.1 or higher and publishing to npm should fix the issue.

Workaround

The yarn add and yarn upgrade commands do respect the latest tag, so a workaround is to run yarn upgrade @commitlint/cli and discard the diff to package.json but commit your updated yarn.lock file.

Support additional field data

Add rules for additional fields, both optional and required.

To enable this the fieldPattern, noteKeywords, referenceActions in conventional-commits-parser can be used, consider abstracting away the differences between fields, and references.

footer-leading-blank is complaining when there is no footer

When attempting to submit a commit:

chore: force add README.md
This is designed to be used in combination with .gitignore ./README.md when dynamically generating documentation.

I am getting:

⧗ input: chore: force add README.md
✖ footer must have leading blank line [footer-leading-blank]
⚠ tense of body must be present-imperative. Verbs in other tenses: is - present-third-person,generating - present-participle,starting - present-participle,is - present-third-person,commits - present-third-person,staged - > past-tense [body-tense]
⚠ header must not be shorter than 30 characters [header-min-length]
⚠ message must be lowerCase [subject-case]
✖ found 1 problems, 3 warnings

There is no footer, therefore there must be no warning.

Match IDs?

Can commitlint validate numerical IDs?

PRJ-123: valid commit
PRJ-789: valid commit
MFB-123: valid commit
MFB: invalid commit

"scope-empty": [2, "always"] is triggering an error when it shouldn't

chore: update documentation generation

This commit has no scope. However, I am getting an error:

⧗ input: chore: update documentation generation
✖ scope must be empty [scope-empty]
✖ found 1 problems, 0 warnings

Use with squashed pr flow

I am trying to use conventional-changelog-lint with a squash git flow and with github.com where I do not have access to a server pre-receive githook. Looking for guidance as in #35 (thank you btw).

In my squash git flow:

1. only squashed PRs are allowed.
2. There is one PR per concern.
3. Only one changelog addendum per concern (and PR).
4. Eached merged PR does a RC semver bump and tag.
5. On release, all the RCs from the the previous release to now get added to the changelog and new release is made.

In my ci test I can have conventional-changelog-lint --from=master --to=current-branch and catch all of the new commits from the fork point, but I would be grand to only require the conventional commit message on the PR message and not on all of the commits that end up squashed.

For step 3 i can have pr template to guide, but there is no way to lint before the merge to master right? I can lint in master and fail the CI, requiring someone to amend the commit mesg in master.
For step 5, can --from and --to support other git refs besides branch name?

Error when linting with config-lerna-scopes

When trying to lint a message with config-lerna-scopes, the following error is issued:

$ echo "chore(api): fix something in api's build" | npx commitlint
/Users/quentinroy/Workspace/reacolo/node_modules/@commitlint/cli/cli.js:130
		throw err;
		^

TypeError: Cannot read property 'map' of undefined
    at getPackages (/Users/quentinroy/Workspace/reacolo/node_modules/@commitlint/config-lerna-scopes/index.js:13:3)
    at scope-enum (/Users/quentinroy/Workspace/reacolo/node_modules/@commitlint/config-lerna-scopes/index.js:6:37)
    at /Users/quentinroy/Workspace/reacolo/node_modules/@commitlint/core/lib/library/execute-rule.js:23:28
    at Promise (<anonymous>)
    at /Users/quentinroy/Workspace/reacolo/node_modules/@commitlint/core/lib/library/execute-rule.js:21:26
    at Promise (<anonymous>)
    at exports.default (/Users/quentinroy/Workspace/reacolo/node_modules/@commitlint/core/lib/library/execute-rule.js:14:9)
    at /Users/quentinroy/Workspace/reacolo/node_modules/@commitlint/core/lib/load.js:109:44
    at Array.map (<anonymous>)
    at /Users/quentinroy/Workspace/reacolo/node_modules/@commitlint/core/lib/load.js:108:79

After investigation, it seems the plugin relies on lerna/lib/Repository#packages which does not exist anymore (at least with lerna 2.4.0)

ENOENT: no such file or directory, open '.git/COMMIT_EDITMSG'

When the .git directory is not in the same path than your execution directory, this error is thrown

$ pwd                                                                                               
/Users/javier/Documents/tdaf-pibot/paco                                       
$ node_modules/.bin/conventional-changelog-lint -e                                                  
/Users/javier/Documents/tdaf-pibot/paco/node_modules/conventional-changelog-lint/distribution/cli.js:161                                                                         
        throw error;                                                                                                                                                                       
        ^                                                                                                                                                                                  
                                                                                                                                                                                           
Error: ENOENT: no such file or directory, open '.git/COMMIT_EDITMSG'                                                                                                                       
    at Error (native)                                                                                                                                                                                                                             

in the example, the .git directory is /Users/javier/Documents/tdaf-pibot/.git but the node project with the package.json is in /Users/javier/Documents/tdaf-pibot/paco (one directory inside)

I think this can be solved by executing git rev-parse --show-toplevel for obtaining the current git directory and make an absolute path in https://github.com/marionebl/conventional-changelog-lint/blob/master/source/library/get-messages.js#L29

WDYT?

GHPages docs can not fetch README

http://marionebl.github.io/commitlint/#/ shows a not very nice "not found" message instead of the README. Local development works just fine.

Consider using retext-pos instead of pos-js

Consider using retext-pos instead of pos-js. This would yield the following benefits:

• Actively maintained
• Tap into the retext eco system for further functionality

language detection error

Just had the following output from commitlint, where it has incorrectly detected the language:

input: feat(commitlint-config-default): add default commitlint rules
⚠   commit must be in languague "eng", was one of: fra, cat, src, spa, sco [lang]
⚠   found 0 problems, 1 warnings

Running npx franc-cli "feat(commitlint-config-default): add default commitlint rules" yields cat as the result 😖

(Also note the minor typo in the error message)

Feature request: support more options for scope-case rule

Hi! I want camelCase as scope-case rule. I think we can use lodash to avoid coding. Like:

https://lodash.com/docs/4.17.4#camelCase
https://lodash.com/docs/4.17.4#kebabCase
https://lodash.com/docs/4.17.4#snakeCase

And, we could throw an error if an invalid option is set? I think defaulting to lowercase is not good.

If you think that this approach is ok, I can try to make a PR with this feature.

Best.-

use with PR messages

This is not necessarily a conventional-changelog-lint concern but I would like to use conventional-changelog-lint to link PR commit messages before code is merged ... and reject the PR if the message fails linting.

GIt does not have a pre-merge hook - any other conventional-changelog-lint users looking at the same that might have pointers?

prompt: add enum picker and prompts for fields

I've been using cz-cli and have just tried out commitlint/prompt. Something that commitlint/prompt offers that I wish existed in cz-cli is the character count for the type/scope/subject. On the other hand, I really like cz-cli's ability to prompt for every part of the commit message (type, scope, subject etc) with individualized instructions. cz-cli also offers a picker for the commit type with explanation of each option. It'd be fantastic if commitlint can incorporate those great features from cz-cli.

prompt: Error when using the word undefined in subject line.

❯ subject: add undefined to value type

The following error was thrown:
Error: vorpal._exec was called with an undefined command.

Support configuring parserOpts (conventional-commits-parser)

Is it possible?

Prevent default merge of angular extend

I don't know if I'm using the library wrong but it seems it always extends my custom rules with the ones from the angular config: const opts = merge({}, defaults, pick(config, 'extends')); So if I don't want to extend any config but define my own rules, I always end up with angular + my own.

Please enlighten me if I don't see it ;) 💡

core: multiple scopes in commit message

Hi,

I have a project where the commitlint is used to enforce the commit message using the angular & lerna-scopes config. This works fine for most messages but it errors for multiple scopes in a message: Example: fix(core,context): fixed some situation.

Is there a configuration to support this or should this be a feature request?

footer-leading-blank searches on false line

Preset support missing

While trying to use jshint preset:

$ conventional-changelog-lint -e -p jshint
/Users/javier/Documents/Proyectos/conventest/node_modules/conventional-changelog-lint/distribution/cli.js:163
        throw error;
        ^

Error: Cannot find module 'conventional-changelog-jshint'
    at Function.Module._resolveFilename (module.js:325:15)
    at Function.Module._load (module.js:276:25)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at /Users/javier/Documents/Proyectos/conventest/node_modules/conventional-changelog-lint/distribution/library/get-preset.js:11:16
    at next (native)
    at step (/Users/javier/Documents/Proyectos/conventest/node_modules/conventional-changelog-lint/distribution/library/get-preset.js:7:191)
    at /Users/javier/Documents/Proyectos/conventest/node_modules/conventional-changelog-lint/distribution/library/get-preset.js:7:451
    at new Promise (/Users/javier/Documents/Proyectos/conventest/node_modules/conventional-changelog-lint/node_modules/babel-polyfill/node_modules/core-js/modules/es6.promise.js:197:7)
    at /Users/javier/Documents/Proyectos/conventest/node_modules/conventional-changelog-lint/distribution/library/get-preset.js:7:99

After installing the module conventional-changelog-jshint (it's not in the doc that this should be done) it seems it's still using the angular one.

$ conventional-changelog-lint -e -p jshint
⧗   input: [[CHORE]] Dependencies setup
✖   message may not be empty [subject-empty]
✖   message may not end with full stop [subject-full-stop]
✖   type may not be empty [type-empty]
✖   type must be one of ["chore", "docs", "feat", "fix", "perf", "refactor", "style", "test"] [type-enum]
✖   found 4 problems, 0 warnings

Document or fix linting on shallow clones

Shallow cloned repository yield errors via git-raw-commits. conventional-changelog-lint should either document how to circumvent these limitations or support commit listing on shallow clones, too.

see #6

error on commit, if package.json in subdirectory

In root directory(has .git) make subdirectory and in her package.json with "commitmsg": "conventional-changelog-lint -e". After trying commit I have:
Error: Command failed: git rev-parse --show-toplevel
fatal: Not a git repository: '.git'

Add support for ignoring 'fixup!' commits

Since git gained support for 'fixup' and 'autosquash' these commits violate the commitizen specification. But they will be fixed when the autosquash gets over them and rebases.

Replace array config value rather than override element(s)

At first, thank you for your great work. conventional-changelog-lint with "husky" (my preference) really helps to keep clear commit messages with no pains.

BTW, I noticed that user configuration value, if it is an Array value, overrides element(s) of the value of sharable configuration. I don't know it is designed but it seems to be nice if user value replaces sharable configuration value rather than overriding.

For example:

conventional-changelog-lint-config-extendee/index.js
(in sharable configuration package: conventional-changelog-lint-config-extendee)

'use strict';

module.exports = {
    rules: {
        'type-enum': [
            2,
            'always',
            [
                'extendee-type-1',
                'extendee-type-2'
            ]
        ]
    }
};

.conventional-changelog-lintrc (user config)

{
    "extends": [
        "extendee"
    ],
    "rules"  : {
        "type-enum": [
            2,
            "always",
            [
                "user-type"
            ]
        ]
    }
}

Steps

When I run conventional-changelog-lint,

echo "invalid message" | conventional-changelog-lint

It produces the following result.

⧗   input: invalid message
✖   type must be one of ["user-type", "extendee-type-2"] [type-enum]
✖   found 1 problems, 0 warnings

Expected result

✖   type must be one of ["user-type"] [type-enum]

The user config's ["user-type"] replaces sharable configuration's ['extendee-type-1', 'extendee-type-2'].

Actual result

✖   type must be one of ["user-type", "extendee-type-2"] [type-enum]

The user config's ["user-type"] overrides a part of sharable configuration's ['extendee-type-1', 'extendee-type-2'].

Environment

Node.js 7.x.x + conventional-changelog-lint 1.1.0

Cannot lint tag commits: unknown revision or path not in the working tree

Whenever TravisCI builds a tag, conventional-changelog-lint fails. It is working fine when TravisCI builds a pull request (in a branch).

Any ideas? Is my lint command wrong? The command is:

conventional-changelog-lint --from master

• Node version: v4.4.7
• npm version: 3.10.3
• conventional-changelog-lint version: 1.0.0

Example of a TravisCI failure: https://travis-ci.org/mozilla/sign-addon/jobs/143130310

Complete error:

/home/travis/build/mozilla/sign-addon/node_modules/conventional-changelog-lint/distribution/cli.js:163
    throw error;
    ^
Error: fatal: ambiguous argument 'master..HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
    at DestroyableTransform._transform (/home/travis/build/mozilla/sign-addon/node_modules/conventional-changelog-lint/node_modules/git-raw-commits/index.js:54:30)
    at DestroyableTransform.Transform._read (/home/travis/build/mozilla/sign-addon/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:159:10)
    at DestroyableTransform.Transform._write (/home/travis/build/mozilla/sign-addon/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:147:83)
    at doWrite (/home/travis/build/mozilla/sign-addon/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:313:64)
    at writeOrBuffer (/home/travis/build/mozilla/sign-addon/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:302:5)
    at DestroyableTransform.Writable.write (/home/travis/build/mozilla/sign-addon/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:241:11)
    at Socket.ondata (_stream_readable.js:542:20)
    at emitOne (events.js:82:20)
    at Socket.emit (events.js:169:7)
    at readableAddChunk (_stream_readable.js:153:18)

Does the README example work?

The README has:

echo '{"extends": ["@commitlint/config-angular"]}' > .commitlintrc

Looking at the code, I see:

	const legacy = rc('conventional-changelog-lint');
	const legacyFound = typeof legacy.config === 'string';

	const found = resolveable('./commitlint.config');
	const raw = found ? importFrom(process.cwd(), './commitlint.config') : {};

So it seems that the preferred config file name is commitlint.config.js rather than .commitlintrc?

$ echo "foo" | $(npm bin)/commitlint
⧗   input: foo
✔   found 0 problems, 0 warnings

$ mv .commitlintrc commitlint.config.js

$ echo "foo" | $(npm bin)/commitlint
⧗   input: foo
✖   message may not be empty [subject-empty]
✖   type may not be empty [type-empty]
✖   found 2 problems, 0 warnings

Enable "all"/* scopes in commit message

Along similar lines of https://github.com/marionebl/commitlint/issues/75 (especially in a multi-repo) I think it is useful to have a scope for "everything." For example, I am setting up commitlint in an early-stage Lerna multi-repo, which means making commits to add commitlint. I am not adding commitlint to specific packages, but rather to the project, so the change affects all the possible scopes supported by config-lerna-scopes.

I can obviously bypass validation for this type of commit in the meantime, but if that becomes a habit for the team, other types of errors could creep in unless we all ensure we run once to verify the output's only error is scope related. Just overall seems like a better experience to have a way to make these types of commits with accurate messages without getting an error (especially given the superfluous warnings I am also getting, mentioned in other issues).

I've seen some projects use * or all, maybe config-lerna-scopes could add a valid scope along those lines or allow a configuration to define some additional valid scopes that don't directly map to module names?

⧗   input: chore(*): add commitlint
✖   scope must be one of [..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ..., ...] [scope-enum]
⚠   ...
⚠   ...
✖   found 1 problems, 2 warnings