Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

New rule proposal: Flag duplicate literals

See original GitHub issue

Please describe what the rule should do:

This rule should flag uses of duplicate literals in the same file. The goal of this rule is to recommend that those duplicate literals be combined into one variable, which increases maintainability (by solving the problem of a user changing only a subset of the literals in the file, resulting in inconsistent behavior).

It is assumed that this will only work on literals in the same file. No attempt will be made to cross-reference other JS files to look for duplicates across files.

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

[ ] Enforces code style [ ] Warns about a potential error [x] Suggests an alternate way of doing something [ ] Other (please specify:)

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

/**** 1. If conditions written as quick one-liners ****/
if (/myPattern/.test(str)) {

// Later...

if (/myPattern/.test(str) && somethingElse()) {

/**** 2. Validation configuration in popular libraries ****/

const MyModel = Backbone.Model.extend({
    validation: {
        WorkEmail: {
            pattern: /^[^<>:"^/|%?*\\]*$/,
            message: "Email cannot contain special characters"
        PersonalEmail: {
            pattern: /^[^<>:"^/|%?*\\]*$/,                     // <-- Duplicated RegExp literal
            message: "Email cannot contain special characters" // <-- Duplicated string literal

/**** 3. Reusing a literal already in a variable (see Bikeshedding Question 1 below) ****/
const myRegEx = /^somePattern$/;

// Later...

if (/^somePattern$/.test(str)) {
    // ...

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

This is a common maintainability refactor, library-independent, and can seriously save time when those duplicated literals need to be changed later.

Some bikeshedding questions:

  1. Should this rule also flag a literal that is already in a variable (and simply reused), or should that fall under another rule? (See example 3 above)
  2. What literals should and shouldn’t be flagged, and what sort of options should we supply?
    • My proposal is we should flag string, RegExp, and numeric literals by default, and allow users to opt out of any of those types using basic rule options. It would also be great to allow specific exceptions.
    • I don’t think we should flag boolean literals because they are ubiquitous and obvious and creating a variable just for a boolean is pretty silly most of the time. I wouldn’t be opposed to adding an option to flag booleans (as an opt-in stricter check), but I don’t think it’s needed.
    • It might make sense to check only strings and RegExp literals at first, since there could be conflicts with no-magic-numbers for numeric literals. I’d be okay with that too.

I’ll champion this.

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:2
  • Comments:27 (27 by maintainers)

github_iconTop GitHub Comments

not-an-aardvarkcommented, Feb 25, 2017

Could you explain the value of doing that? I don’t understand why we would want to add options to make this similar to no-magic-numbers. In my mind, the rules are enforcing different things – no-magic-numbers requires “magic” values to be given a semantic meaning, whereas no-duplicate-literals prevents code duplication. I agree that there’s some overlap there, but the rules have significantly different goals, so I’m not convinced it’s worth trying to combine them. I think having a no-magic-numbers and a no-duplicate-literals rule would be fine.

platinumazurecommented, Feb 25, 2017

Strongly agree with @not-an-aardvark that this proposal is completely different from no-magic-numbers.

Read more comments on GitHub >

github_iconTop Results From Across the Web

New rule proposal: prefer-regex-literals · Issue #12238 - GitHub
Please describe what the rule should do: Suggests to use regex literals instead of RegExp()/new RegExp() when these calls have: One argument ...
Read more >
SA0187 : Duplicated string literals complicate the refactoring
The rule reports more than one usage of a single string literal. Duplicating the same string literal makes the process of refactoring more...
Read more >
Java static code analysis: String literals should not be duplicated
Duplicated string literals make the process of refactoring error-prone, since you must be sure to update all occurrences. On the other hand, constants...
Read more >
SE-0354 (Second Review): Regex Literals - Swift Forums
This review is part of a collection of proposals for better string processing in Swift. The proposal authors have put together a proposal...
Read more >
Duplicate literals - IBM
Literals are duplicates only if their specifications are identical, not if the object code assembled happens to be identical. When two literals specifying ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found