tools: add and apply eslint rule no-regex-spaces

[gengjiawen]

Expert from https://eslint.org/docs/rules/no-regex-spaces:

Regular expressions can be very complex and difficult to understand, which is why it’s important to keep them as simple as possible in order to avoid mistakes. One of the more error-prone things you can do with a regular expression is to use more than one space, such as:

var re = /foo   bar/;

In this regular expression, it’s very hard to tell how many spaces are intended to be matched. It’s better to use only one space and then specify how many spaces are expected, such as:

var re = /foo {3}bar/;

Now it is very clear that three spaces are expected to be matched.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[cjihrig]

Personally, I find this less readable.

[gengjiawen]

My main thought is that:

• regex should be compact
  too many spaces will be make it hard to read IMHO, like this one below:

  node/test/parallel/test-repl.js

  Line 541 in d3d79d9

  /^ at .*/,

• This rule is in "eslint:recommended"
• used by many libs https://github.com/graphql/graphql-js/blob/9dc9a56e174371c12c4b69a32d4b1e571f96c346/.eslintrc.yml#L109

But I am not quite insistent on this. If most @nodejs/lint members not a a fan of this rule, I will drop this pr (Not quite sure how to start a poll, use emoji ?).

[Trott]

(Not quite sure how to start a poll, use emoji ?).

I'd rather we have discussions and avoid polls (meaning that one person giving a good reason for doing or not doing something is better than a dozen people saying "+1" or "-1".).

I'd prefer we don't do this. My feelings aren't strong enough to block it, but:

• I agree with @cjihrig that it doesn't always improve readability.

• When a message gets updated, I'd prefer to be able to copy/paste the message rather than have to modify it for the number of spaces.

• This change could also mess things up when someone looks for usage of a message via grep or similar tool.

That said, I think a few of these would benefit from being changed from regular expressions to calls to String.prototype.includes().

[gengjiawen]

@Trott Most cases involved in this rule looks like can be done using snapshot test (something like https://jestjs.io/docs/en/snapshot-testing). Maybe a different issue though.

I will close this.