CR - max-len: {ignoreRegExpLiterals: true} is too permissive

Tell us about your environment

• ESLint Version: 4.3.0
• Node Version: master
• npm Version: 5.3.0

What parser (default, Babel-ESLint, etc.) are you using? N/A

Please show your full configuration: https://github.com/nodejs/node/blob/master/.eslintrc.yaml https://github.com/nodejs/node/blob/master/lib/.eslintrc.yaml

max-len: [error, {code: 80,
                  ignoreRegExpLiterals: true,
                  ignoreUrls: true,
                  tabWidth: 2}]

What did you do? Please include the actual source code causing the issue.

01: function fatalError(e) {
02:   if (typeof e.stack === 'string') {
03:     process._rawDebug(e.stack);
04:   } else {
05:     const o = { message: e };
06:     Error.captureStackTrace(o, fatalError);
07:     process._rawDebug(o.stack);
08:   }
09:  if (process.execArgv.some((e) => /^--abort[_-]on[_-]uncaught[_-]exception$/.test(e))) {
10:    process.abort();
11:   }
12:   process.exit(1);
13: }

What did you expect to happen? L09 should error. Even though we have ignoreRegExpLiterals: true such cases should not be allowed. It’s not the RegExp that is super long, it’s the multiple expressions in that single line that caused it to be too long. I understand it’s not a straightforward problem to solve, but IMHO it could be minimized with some heuristics.

What actually happened? Please include the actual, raw output from ESLint. Nothing (i.e. lint passed)

[not-an-aardvark]

Thanks for creating an issue. In https://github.com/eslint/eslint/issues/8189, there was some discussion about changing the behavior of ignoreRegExpLiterals to subtract the length of regex literals from the total line length, rather than ignoring lines with those literals entirely. Would that satisfy your use case?

[ljharb]

I’m suggesting that an ignore of true means “ignore it” - meaning, disregard its length - I’m not suggesting any non-boolean value be allowed there.

Measuring complexity is imo way out of scope of max-len (which is itself often used as a poor proxy for complexity).