In a commit title "foo: bar baz", the text "bar baz" is considered a **subject**, but not if the text "foo" contains special chars

[knocte]

Steps to Reproduce (for bugs)

Develop a local plugin like documented here:
https://github.com/conventional-changelog/commitlint/blob/master/docs/reference-plugins.md#local-plugins
So the config file starts like this:

module.exports = {
    parserPreset: 'conventional-changelog-conventionalcommits',
    rules: {
        'body-leading-blank': [1, 'always'],
        'footer-leading-blank': [1, 'always'],
        'footer-max-line-length': [2, 'always', 150],
        'header-max-length': [2, 'always', 50],
        'subject-full-stop': [2, 'never', '.'],
        'type-empty': [1, 'never'],
        'type-space-after-colon': [2, 'always'],
        'subject-lowercase': [2, 'always'],
    },
    plugins: [
        {
            rules: {
                'subject-lowercase': ({subject}) => {
                    if (subject === null || subject === undefined) {
                       // otherwise, String(null) might give us the stupid string "null"
                        throw new Error('Unexpected subject===null or subject===undefined happened');
                    }
        
                    let offence = false;
                    if (subject != null && subject.length > 1) {
                        let firstIsUpperCase = subject[0].toUpperCase() == subject[0];
                        let firstIsLowerCase = subject[0].toLowerCase() == subject[0];
                        let secondIsUpperCase = subject[1].toUpperCase() == subject[1];
                        let secondIsLowerCase = subject[1].toLowerCase() == subject[1];
        
                        offence = firstIsUpperCase && (!firstIsLowerCase)
                            // to whitelist acronyms
                            && (!secondIsUpperCase) && secondIsLowerCase;
                    }
        
                    return [
                        !offence,
                        `Please use lowercase as the first letter for your subject, i.e. the text after your area/scope`
                    ];

...

1. Run the plugin against a commit msg like foo: bar baz, it works.
2. Run the plugin against a commit msg like foo.bar: baz or foo-bar: baz or foo,bar: baz, then....

Current Behavior

It crashes with "Unexpected subject===null or subject===undefined happened" because of the assertion.

Expected Behavior

It should not crash. Subject should always be the text after the first colon.

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

No idea, didn't yet dive in the source code of commitlint sorry.

Your Environment

Executable	Version
commitlint --version	17.1.2
git --version	2.37.3
node --version	v16.17.0

[escapedcat]

The type is usually just one word. As listed in the convetions, right?
I could imagine this is what commitlint gets from the conventional-changelog-conventionalcommits parser. Not 100% sure though.

[knocte]

The type is usually just one word. As listed in the convetions, right?

The first thing I did when adopting commitlint myself is disable all the rules about "type". In my company, we use what goes before the colon as an area/scope. Still, I decided to adopt commitlint because its configuration allowed me to stop treating the "type" as a kind of an enum, if you know what I mean.

[knocte]

As listed in the convetions, right?

And actually, I just visited that URL, and it clearly states the optional part after the type before the colon: [optional scope]. Why can't the optional scope have non-alphanumeric chars like dot, dash, etc?

[escapedcat]

I can't answer this without checking the parser. Don't have time for this currently.

I think your best chance is to search in the issues here or have a look at the parser code.
Maybe other users in the issues tried to achieve something similar to you and used a plugin only or a different parser. Not sure.
Sorry I can't help a lot with this.

[knocte]

to achieve something similar to you and used a plugin

I detected this bug when using a plugin. My workaround was to use {header} instead of {subject}; this way I extract the subject myself inside my local plugin.

[AdeAttwood]

Hi all, it's been a while.

This is defo the parser regex. I still have an upstream bug outstanding to amend the regex. I would suggest changing the parser regex, here is an example for fixing a - in the subject #2694 (comment).