enhance "quotes" fixer to take "avoidEscape" into consideration

[billiegoose]

What rule do you want to change?
eslint --fix rewrote my template strings (containing single quotes) into single quote strings (containing escaped single quotes) despite the fact that the avoidEscape setting was true.

I'd like to enhance the fixer function for https://eslint.org/docs/rules/quotes to take the avoidEscape setting into account when converting quotes from backtick to single quotes.

Does this change cause the rule to produce more or fewer warnings?
exactly the same

How will the change be implemented? (New option, new default behavior, etc.)?
I would modify this function to have a second argument, avoidEscape:

eslint/lib/rules/quotes.js

Lines 48 to 69 in 4aeeeed

	QUOTE_SETTINGS.double.convert =
	QUOTE_SETTINGS.single.convert =
	QUOTE_SETTINGS.backtick.convert = function(str) {
	const newQuote = this.quote;
	const oldQuote = str[0];
	if (newQuote === oldQuote) {
	return str;
	}
	return newQuote + str.slice(1, -1).replace(/\\(\$\{|\r\n?|\n|.)|["'`]|\$\{|(\r\n?|\n)/gu, (match, escaped, newline) => {
	if (escaped === oldQuote || oldQuote === "`" && escaped === "${") {
	return escaped; // unescape
	}
	if (match === newQuote || newQuote === "`" && match === "${") {
	return `\\${match}`; // escape
	}
	if (newline && oldQuote === "`") {
	return "\\n"; // escape newlines
	}
	return match;
	}) + newQuote;
	};

Please provide some example code that this change will affect:

e.g. with these rules:

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

and this code

console.log(`'a.txt' exists`)

running eslint --fix would generate the following:

console.log("'a.txt' exists")

What does the rule currently do for this code?
currently the fixer generates this:

console.log('\'a.txt\' exists')

which is technically correct but not as nice

What will the rule do after it's changed?
rule is same, only fixer changes

Are you willing to submit a pull request to implement this change?
yup

---

Note: kinda related to #10627

closes standard/standard#1380

[mdjermanovic]

Hi @wmhilton, thank you for the proposal and for the relevant link.

Someone will correct me if I'm wrong, I think that this enhancement would be incompatible with #10627 and that the question should the rule report error should be resolved first.

[feross]

@mdjermanovic I don't see how the proposed change in this issue is incompatible with #10627.

If I understand correctly, this issue is proposing that when the rule "quotes": ["error", "single", { "avoidEscape": true, "allowTemplateLiterals": false }] is in effect, ESLint should prefer correcting this invalid code

console.log(`'a.txt' exists`)

to this

console.log("'a.txt' exists")

rather than to this

console.log('\'a.txt\' exists')

Does that make sense?

[mdjermanovic]

Makes sense, but the proposed change in #10627 is no error reported. That's why this is incompatible.

Or am I reading something wrong, one example is with single quotes the other with double quotes but it's the same situation with different proposals?

[feross]

Makes sense, but the proposed change in #10627 is no error reported

I see. The reason I though this was unrelated is that we specify "allowTemplateLiterals": false and also "avoidEscape": true so there's no ambiguity about what type of quotes we prefer to be used to avoid escaping.

[mdjermanovic]

I see. The reason I though this was unrelated is that we specify "allowTemplateLiterals": false and also "avoidEscape": true so there's no ambiguity about what type of quotes we prefer to be used to avoid escaping.

Yes, but the rule shouldn't work differently with the explicit option's value than with the implicit default value (false), so it's the same whether you put "allowTemplateLiterals": false or omit the option.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.