sindresorhus/eslint-plugin-unicorn

Do you want to work on this issue?

You can request for a bounty in order to promote it!

Rule proposal: `no-useless-interpolation` #1261

karlhorky posted onGitHub

<!-- 🍩 Please don't ignore this template -->

<!-- 1️⃣ Explain here why this rule would be beneficial -->

Hi there! 👋 First of all, thanks again for this plugin, super helpful, the things available in this plugin.

I wanted to propose a new rule to address a pattern that I have seen from a lot of our students at @upleveled - writing overly complex patterns with unnecessary interpolations in template strings (eg. a single string variable, or a string literal, or multiple string literals).

Fail

<!-- 2️⃣ Specify an example of code that should be detected -->

const withString = `${str}`;
const withStringLiteral = `${'abc'}`;
const withMultipleStringLiterals = `${'abc'}${'def'}`;

Pass

<!-- 3️⃣ Specify an example of code that would be accepted in its place -->

const withString = str;
const withStringLiteral = 'abc';
const withMultipleStringLiterals = 'abcdef';

Implementation ideas

Looking into the ASTExplorer, I guess the simple version of the first failure case below would be:

  • only 1 element in TemplateLiteral.expressions (an Identifier)
  • only 2 elements in TemplateLiteral.quasis, all empty strings

For the literals, I guess no limit to the quasis, but every element in expressions should be a Literal.


Oh, I just realized this may be difficult to implement without variable type information.

What is the position of the project on using type information (eg. TypeScript, JSDoc) in rules?

posted by karlhorky over 3 years ago

🤦‍♂️ Ohh I know why this rule seemed so familiar to me, I proposed something similar over at @typescript-eslint/eslint-plugin some time ago:

https://github.com/typescript-eslint/typescript-eslint/issues/2846

If you think this is a better place for this (instead of here) then I will close this.

posted by karlhorky over 3 years ago

Ah and background of a similar proposal in the ESLint repo: https://github.com/eslint/eslint/issues/10798

posted by karlhorky over 3 years ago

Looking into the ASTExplorer, I guess the simple version of the first failure case below would be:

This is not right they are the same, one expression plus two empty quasis.

posted by fisker over 3 years ago

Oh, I just realized this may be difficult to implement without variable type information.

Actually, not really nessary, if it's unknown type, we can assume it's type-casting, const foo = String(bar) still better than template.

posted by fisker over 3 years ago

The rule could be two parts

  1. forbid string literal as expression.
  2. No expression-only template.

Update:

String concatenation should fobid too

`before${ "head" + expression + "tail" }after`

posted by fisker over 3 years ago

I think we can accept it.

posted by fisker over 3 years ago

One note, taged templates should not reported.

posted by fisker over 3 years ago

This is now accepted.

posted by sindresorhus over 3 years ago

Note: the `${str}` case is already covered by the disallowTemplateShorthand option of the core no-implicit-coercion rule.

posted by EvgenyOrekhov over 3 years ago

I will work on it!

posted by B2o5T about 3 years ago

I started few month ago, but I can't remember the progress...

https://github.com/fisker/eslint-plugin-unicorn/commits/no-useless-interpolation

posted by fisker about 3 years ago

is anything happening on this?

posted by damiangreen almost 2 years ago
posted by KurtPreston over 1 year ago

Some progress on that? I could includes functions like ${chalk.bold("Hello")} to be just chalk.bold("Hello")?

posted by rentalhost about 1 year ago

Looks like this was implemented in @typescript-eslint/no-useless-template-literals

posted by EvgenyOrekhov 12 months ago

Fund this Issue

$0.00
Funded
Only logged in users can fund an issue

Pull requests