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

Disable backtick quotes if it is not a template #838

Closed
ghost opened this issue Apr 5, 2017 · 21 comments
Closed

Disable backtick quotes if it is not a template #838

ghost opened this issue Apr 5, 2017 · 21 comments

Comments

@ghost
Copy link

ghost commented Apr 5, 2017

Now you could write either

let a = 'hello'

or

let a = `hello`

And it would pass standard linter for both cases, even if in the second case the template doesn't have any interpolated variables and in fact is just a different form of a string. So you could mix both forms, something conceptually similar to mixing " and ' quotes.

ESLint allows us to prevent this behavior by adding a rule

"quotes": [2, "single"]

This rule makes ESLint to throw an error for this

let a = `hello`

but don't throw any errors for this

let subject = 'world'
let a = `hello, ${world}`

Also see this issue in ESLint.

@dcousens
Copy link
Member

dcousens commented Apr 5, 2017

NACK, only because it means if I am intermittently using templates, I have more rules to remember or otherwise have standard bark at me.
Reminds me of #791

@yoshuawuyts
Copy link
Contributor

yoshuawuyts commented Apr 5, 2017

I don't mind this, it'd warn for weird mixing stuff like:

var a = `hello` + '  my ' + `brethren`

Standard would tell you that you probably meant to either use single quotes or interpolate, but definitely not the weird thing right there above. I feel that this would indeed be in the spirit of our current approach to #791. There's a default way to do things, and we warn if people are deviating from it without there being a need to.

note: I don't really mind whatever way it goes, just like - feel it's consistent with the ruleset we've been applying so far.

edit: Also consider this:

var foo = 'hello people' // ✓
var bar = `nope, or dope? who knows` // ✓
var baz = "vinegar sauce" // 𝗑 - not sure why

@dcousens
Copy link
Member

dcousens commented Apr 6, 2017

it'd be simpler to just disable non-backtick quotes entirely

@ghost
Copy link
Author

ghost commented Apr 6, 2017

@dcousens In this case it would be necessary to update README.md and consequently the front page of https://standardjs.com , as they both mandate to use

Single quotes for strings – except to avoid escaping

@skbolton
Copy link

skbolton commented Apr 6, 2017

Yeah personally I use back ticks all the time that way I am always ready to interpolate

@feross
Copy link
Member

feross commented Apr 7, 2017

it'd be simpler to just disable non-backtick quotes entirely

I like having two types of quotes to indicate intent. Interpolating is rare enough that I appreciating having it explicitly called out by the ` character.

@skbolton
Copy link

skbolton commented Apr 7, 2017

Well really there is no harm leaving a template string as an un-interpolated string. Yeah normally it means that you are going to interpolate but I think it would be weird to have that as a rule

@ghost
Copy link
Author

ghost commented Apr 7, 2017

There are also a couple of other arguments against making backtick quotes preferred for all strings:

  1. Using backticks for strings without interpolated variables adds a burden of additional care about escaping, because if you are not planning to interpolate, but for some reason want to have in your string literally ${console}, then it should be properly escaped in order to avoid runtime errors or perhaps even vulnerabilities. It is also not always possible for any linter to automatically determine the cases when an expression should be escaped and when it is not, like in this example with ${console}.
  2. Making backticked strings to be the only possible strings to use instead of single quoted ones would break all the codebases in pure ES5 that can't use string template syntax, but use standard to enforce style rules.

@blgm
Copy link

blgm commented Oct 12, 2017

I can see how disabling backticks would fit with Standard's existing philosophy

  • In ES5, the the rule is that you must use single quotes, except when you need the extra functionality of double quotes (e.g. to quote a single quote)
  • In ES6, a rule saying that you must use single quotes, except when you need the extra functionality of double quotes or backticks would make sense. Extra functionality would include:
    • quoting other types of quote
    • templates
    • literal new lines

@romanzoller
Copy link

I also think this would make sense, such that

Single quotes for strings – except to avoid escaping

is enforced. Note that the implementation is very simple: Remove the "allowTemplateLiterals": true option from the quotes rule. Despite the naming of the option, "allowTemplateLiterals": false actually still allows template literals when their extra functionality is used, see examples in the doc for the quotes rule.

@mightyiam
Copy link
Member

@feross feross added this to the standard v14 milestone Jul 27, 2019
@feross
Copy link
Member

feross commented Jul 27, 2019

Thanks for the input everyone!

I think that we should disallow template literals when placeholders or tagged template features are not used.

console.log('hello there')    // ✓ ok
console.log("hello there")    // ✗ avoid
console.log(`hello there`)    // ✗ avoid

$("<div class='box'>")        // ✓ ok
console.log(`hello ${name}`)  // ✓ ok

Only 1 ecosystem package (webtorrent-desktop) needed to be updated, and it was just one line that needed the update: webtorrent/webtorrent-desktop@c8f1e23

I'm going to ship this in v14.

@feross feross closed this as completed in c003b84 Jul 27, 2019
@mightyiam
Copy link
Member

Lovely!

@ArmorDarks
Copy link

And what about this case?

console.log(`I'd like to quote someone: "That will force manual escaping on me"`)

It seems to be legit, but it's forbidden by the rule.

@mightyiam
Copy link
Member

@ArmorDarks as you know, Standard's preferred quotes are single quotes. Allowing double quotes when the string contains single quotes is one thing. Because single and double quotes are equal in all ways, as far as I know. Since backticks are a different language feature (inline expression and tags), allowing them in order to avoid escape characters is a different consideration.

@langri-sha
Copy link

langri-sha commented Oct 14, 2019

I\'m not sure how I\'m supposed to feel about maintaining sentences like these and being forced to escape manually myself.

This rule is quite problematic, because using backticks without any tags or expressions clearly conveys the intent: this is language being displayed to humans.

@mightyiam
Copy link
Member

@langsri-sha, could you please expand on "this is language being displayed to humans"? I don't quite understand what "language" means here. The string?

@langri-sha
Copy link

@mightyiam here are a few instances where I use backticks because the string is something that's communicated directly to humans:

debug(`Use the Force, Luke!`)
new Error(`Whoops, something went terribly wrong!`)
test(`foo does something`, () => {})

So was able to keep things neat and tidy with just single quotes and backticks. Now there's mixed use of single quotes, double quotes, escape sequences and backticks 😬!

@mightyiam
Copy link
Member

@langri-sha what do you mean by "communicated directly to humans", please? You mean, while those humans are reading the code? Or by test failure messages, error messages and debug logs?

@langri-sha
Copy link

By this I mean strings that are used to express written language. The case the OP makes with:

let a = 'hello'
let a = hello

☝️ I see this more as "I have a problem that I can express strings in two different ways", but I don't think this sufficiently accounts for written language, like this paragraph that I just writing. As I said, we've moved from a consistent use of single quotes and backticks to mixed use of single quotes, double quotes, escape sequences and backticks.

@mightyiam
Copy link
Member

@langri-sha thank you for the explanation. I understand what you mean now.

Personally, it's a non-issue for me. If you have a suggestion, could you please open a new issue with that?

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 26, 2021
suchitg8 pushed a commit to suchitg8/standard that referenced this issue Apr 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

No branches or pull requests

9 participants