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

[Torr6River]

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)

1. 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]

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]

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]

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?