empty commit messages: reads the empty message as invalid input but doesn’t validate it normally.

Torr6River commented 5 years ago

git commit --allow-empty -m ""

Expected Behavior

error message on the empty commit AND validate as normal

Current Behavior

/Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/@commitlint/cli/7.2.1/node_modules/@commitlint/cli/lib/cli.js:109
    throw err;
    ^

TypeError: Expected a raw commit
    at parser (/Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/conventional-commits-parser/2.1.7/node_modules/conventional-commits-parser/lib/parser.js:79:11)
    at sync (/Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/conventional-commits-parser/2.1.7/node_modules/conventional-commits-parser/index.js:97:10)
    at $If_1 (/Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/@commitlint/parse/7.1.2/node_modules/@commitlint/parse/lib/index.js:36:13)
    at /Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/@commitlint/parse/7.1.2/node_modules/@commitlint/parse/lib/index.js:42:16
    at new Promise (<anonymous>)
    at parse (/Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/@commitlint/parse/7.1.2/node_modules/@commitlint/parse/lib/index.js:19:9)
    at Object.<anonymous> (/Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/@commitlint/lint/7.2.1/node_modules/@commitlint/lint/lib/index.js:56:45)
    at new Promise (<anonymous>)
    at exports.default (/Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/@commitlint/lint/7.2.1/node_modules/@commitlint/lint/lib/index.js:42:55)
    at Promise.resolve.Promise.all.messages.map.message (/Users/foo/src/wis/common/temp/node_modules/.registry.npmjs.org/@commitlint/cli/7.2.1/node_modules/@commitlint/cli/lib/cli.js:149:66)

Steps to Reproduce (for bugs)

git commit --allow-empty -m ""

Context

Your Environment

Mac OS High Sierra

Executable	Version
`commitlint --version`	7.2.1
`git --version`	2.19.1
`node --version`	10.14.0

escapedcat commented 5 years ago

This is a funny one. We actually do have a check for this.

But for some reason stdin() returns a \n which doesn't count as an empty message.
I guess checking if input is a line-break only would work but the nicer way would be to figure out why this used to work (I guess... did it?) and now apparently input is a \n and it stopped working.

Ideas? @byCedric @marionebl

byCedric commented 5 years ago

Oh wow, nice find! 😄 Ok, so apparently it's expected behavior from Sindre's package get-stdin. The only way I can come up with another solution is the .trim() or even .trimEnd() method. It also trims line breaks, but I'm not sure if it trims too much or has an impact on some rules.

value	trim	trimEnd
`'\n'`	`''`	`''`
`' \n '`	`''`	`''`
`'foo: bar\n'`	`'foo: bar'`	`'foo: bar'`
`'foo: bar\n\ntest\n`	`'foo: bar\n\ntest'`	`'foo: bar\n\ntest'`

escapedcat commented 5 years ago

Haha, funny. Didn't come up with checking get-stdn. Nice!
Checking that linked issue, how would 'foo\nbar\n\n' be treated in your examples?

conventional-changelog / commitlint