Allow enforcing single/double-quotes without preventing use of template literals

How it worked in ESLint 1.0.0 worked perfectly. I could enforce single-quotes everywhere 'quotes': [2, 'single'] and still use template literals when convenient, e.g. if the content had single-quotes so not having to escape it. With ESLint 2.0.0 template literals are now awkwardly forced into the rule and there’s no way to enforce single-quotes without also preventing use of template literals when they’re not strictly required. I don’t want to use double-quotes to prevent having to escape strings containing single-quotes. I want to use template literals, or rather, I already do, and this change makes everything break for me…

I’ve read both https://github.com/eslint/eslint/issues/5147 and https://github.com/eslint/eslint/issues/3090, but I disagree with the conclusion and I think they’re missing this use-case.

To be clear, this used to pass:

~/dev
❯ eslint --version                                                                           
v2.0.0

~/dev
❯ echo "var foo = \`bar 'foo' baz\`;" | eslint --stdin --env=es6 --rule='quotes: [2, single]'

<text>
  1:11  error  Strings must use singlequote  quotes

✖ 1 problem (1 error, 0 warnings)

I would like an option to allow this functionality.

[nzakas]

@IanVS “accepted” was in response to https://github.com/eslint/eslint/issues/5234#issuecomment-183676342

I still think just having an option of quotes that says “allow template literals in addition to my preference” is the simplest and easiest way to resolve this. I don’t see a lot of value in splitting out an entire separate rule for what amounts to one exception.

Maybe if we clean it up a bit, we can have a new schema that’s a bit more readable, like:

quotes: ["error", "double", {
    avoidEscape: true,
    allowTemplateLiterals: true
}]

The quotes rule is one of the oldest rules we have, so it does have a bit of the legacy option feel to it. This would clean it up nicely (I think).

[MiguelCastillo]

Opinionated vote is to have separate rules. It is more clear to me. In projects I am involved in they are both used and they certainly don’t mean the same thing. A tick isn’t a quote… Although a tick does encompass the functionality of a quote. template-string seems very appropriate. And perhaps even add some of the semantics provided with avoid-escape if we feel that we really need it.

I don’t see ticks in the wild very frequently being used in import statements, even though with the restrictions we are imposing we have to:

import x from `x`;

One thing that concerns me is that the mere fact that we have to rephrase several times the intricate differences when ticks are valid in the context of a quote tells me that we are adding complexity in just explaining to the user how to configure eslint. I am not taking into account development complexities.

Also, keeping quotes as is and adding a separate rule for managing ticks gives us breathing room and flexibility for enhancing their behavior without needing to work through the intricate differences each time. Perhaps we want to add a future restriction that template tags can only be of a certain color…

The unfortunate part is that as of right now, my team isn’t able to upgrade (stuck in 1.x) because we have a need to use both, single quotes and ticks. 😕