new rule option request: max-len ignores strings

[ljharb]

Currently, max-len supports ignoreComments, ignoreUrls, etc. I'd like to request an additional option, ignoreStrings.

My rationale is the following:

• strings are an atomic token, and it is a code smell to treat them as anything other than a single unbroken unit.
• trivial changes in the string contents might necessitate the string being re-joined and re-broken, causing unnecessary diff churn
• people use line length limits for many things, but i personally use them as a proxy for limiting line complexity - as such, length isn't actually what i care about.

This affects both inline strings as well as "require" paths and "import from" paths (and should apply to template literals as well as single/double-quoted strings)

[platinumazure]

Sounds good to me, but let's see what the rest of the team thinks.

[jgautsch]

I too would like this, and would be happy to take a crack at a PR.

[ilyavolodin]

So to clarify, should this apply to every node of type Literal or should there be some exceptions?

[ljharb]

@ilyavolodin I was only thinking string and template literals - however, I'd be equally fine with the option being called ignoreLiterals, since if I happened to have a very long number or regex, i wouldn't want to have to split it across lines.

[nzakas]

@eslint/eslint-team does anyone want to champion this?

[alberto]

What is the proposed behaviour here? Ignore the whole line if it contains a string, like ignoreUrls? Discount the length of the string from the line length?

[ljharb]

@alberto i'd be fine with either. discounting the length of the string seems most useful to me, however.

[adamreisnz]

I would like to single out template literal strings specifically for this kind of rule, rather than all strings in general. Usually, template strings will contain HTML which sometimes can be quite lengthy on one line.

[ljharb]

I'm fine with two options - ignoreTemplateLiterals and ignoreStringLiterals, or, ignoreLiterals with an array of options.

[lencioni]

The Airbnb JavaScript style guide now recommends not breaking and concatenating long strings. https://github.com/airbnb/javascript#strings--line-length

[eslintbot]

Hi @ljharb, thanks for the issue. It looks like there's not enough information for us to know how to help you.

Requesting a new rule? Please see Proposing a New Rule for instructions.

[platinumazure]

Can someone please put together a concrete proposal using the "Proposing a Rule Change" instructions above, which answers all of the open questions? If someone can get that put together, I'm willing to champion.

Open questions:

• Should strings and template literals be configurable independently, and if so, how should those options look?
• Should we discount the length of the string from the offending line (but still check that all tokens before the last literal are within the max-len limits)? Or just not report the whole line?
  • What is done for ignoreUrls? Should we follow that behavior? Why or why not?

If we can get consensus around these questions, I think we can move forward with this.

[ljharb]

• Yes, because I don't wish to distinguish between template literals and other string literals - although I don't object to new rule option request: max-len ignores strings #5805 (comment), and configurability is a good thing.
• Personally I think the length of the string should be discounted from the line entirely, but in reality it should be identical to what "ignoreUrls" does.

I'll write what you're requesting now.

[ljharb]

What version of ESLint are you using?
any

What rule do you want to change?
max-len - add an option for ignoreStringLiterals, and an option for ignoreTemplateLiterals.

What code should be flagged as incorrect with this change?

// these warn
// eslint max-len: [2, 10, { "ignoreStringLiterals": false, "ignoreTemplateLiterals": false }]
a = 'too long';
a = `too long`;


// this is correct
// eslint max-len: [2, 10, { "ignoreStringLiterals": true }]
a = 'too long';
// eslint max-len: [2, 10, { "ignoreTemplateLiterals": true }]
a = `too long`;

What happens when the rule is applied to this code now?
It warns on the "this is correct" options.

Note: just like "ignoreURLs", both of these options should cause the entire line on which the literals appear to be ignored for the max-len rule.

[platinumazure]

I will champion @ljharb's proposal.

[vitorbal]

👍 from me.

[ilyavolodin]

👍

[distributedlock]

This would help a lot. 👍

[kaicataldo]

👍

[platinumazure]

@ljharb This is now accepted. Were you thinking of writing a PR?

[ljharb]

If nobody gets to it first, definitely! Just need to find the time :-)

[stephenhuh]

nice job @ljharb , can't wait to see this merged.