Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New rule proposal: prefer-regex-literals #12238

Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion feature This change adds a new feature to ESLint rule Relates to ESLint's core rules

Comments

@mdjermanovic
Copy link
Member

Please describe what the rule should do:

Suggests to use regex literals instead of RegExp()/new RegExp() when these calls have:

  • One argument that is a string literal.
  • Two arguments and they are both string literals.

What category of rule is this? (place an "X" next to just one item)

[X] Suggests an alternate way of doing something (suggestion)

Provide 2-3 code examples that this rule will warn about:

// good, dynamic
new RegExp(pattern);
new RegExp(prefix + "foo");
new RegExp("foo", flags);

// good, regex literals
/^\d\./
/\d\d\.\d\d\.\d\d\d\d/

// bad, this is a very possible error
new RegExp("^\d\.");
new RegExp("\d\d\.\d\d\.\d\d\d\d");

// bad, correct but unreadable
new RegExp("^\\d\\.");
new RegExp("\\d\\d\\.\\d\\d\\.\\d\\d\\d\\d");

Why should this rule be included in ESLint (instead of a plugin)?

I think this is not just a style preference, rather a good practice to avoid an unnecessary level of the string literal syntax on top of the regex syntax. It's error-prone and difficult to reason about escapes of escapes.

Are you willing to submit a pull request to implement this rule?

Yes.

@mdjermanovic mdjermanovic added rule Relates to ESLint's core rules feature This change adds a new feature to ESLint evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Sep 7, 2019
@mdjermanovic mdjermanovic self-assigned this Sep 7, 2019
@platinumazure
Copy link
Member

Yes! I really want to see this in core. 👍 from me.

@mysticatea
Copy link
Member

How about new RegExp(String.raw`\d\d\.\d\d\.\d\d\d\d`);?

@mysticatea mysticatea added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Sep 8, 2019
@mdjermanovic
Copy link
Member Author

How about new RegExp(String.raw`\d\d\.\d\d\.\d\d\d\d`);?

That style indeed doesn't have the problem with double escapes.

First idea was to disallow just string literals (maybe also simple template literals used as strings), but since the rule is prefer-regex-literals it might make sense to disallow this style, too?

@mysticatea
Copy link
Member

since the rule is prefer-regex-literals it might make sense to disallow this style, too?

Yes, I think so.

@mdjermanovic
Copy link
Member Author

I agree! Working on this.

@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Mar 13, 2020
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Mar 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.