Addition of story as commit type

conventional-changelog provides an enum of available commit type values. With the prevalence of storybook in projects, this ticket is advocating for another type to be added to the enum for story to represent commits that contain the addition of storybook stories being added to the repo.

Affected packages

• cli
• core
• prompt
• config-angular

Context

With the addition of storybook to many repos I am working on, I would like to continue to be able to use commitlint and conventional-changelog to enforce good commit hygiene. The addition of a story type, I feel more accurately reflects commits to my repo where I am adding stories.

Your Environment

Executable	Version
commitlint --version	^7.0.0
git --version	2.22.0
node --version	12.6.0

[byCedric]

My pleasure! 😄 If you want a fix now, I’d recommend adding your own set of enums to your project. You can still “extend” from the configuration but only overwrite the type enums 😄 Here is a config for that:

module.exports = {
    extends: '@commitlint/config-conventional',
    rules: {
        'type-enum': [2, 'always', [
            'build',
            'chore',
            'ci',
            'docs',
            'feat',
            'fix',
            'perf',
            'refactor',
            'revert',
            'style',
            'test',
            'story',
        ]],
    },
};

or a more complex approach, without the need of defining everything again:

const config = require('@commitlint/config-conventional');
const types = config.rules['type-enum'][2];

config.rules['type-enum'][2] = ['story'].concat(types);

module.exports = config;

[byCedric]

I think this is also relevant for you. I haven’t got around to update commitlint to the latest conventional commits specification, but basically in a later (probably major) version the default conventional config should be updated without strict type enums. This is because the original spec doesn’t “forbid” to use any type other than fix and feat. Of course, when this is changed we will document an upgrade guide and a way of how to retain the old behavior of stricter types.

I know this doesn’t help you right now, but I hope this gives you some info for the near future 😄