Prefer-template prohibit multi lines
See original GitHub issueWhat rule do you want to change?
Prefer-template
Does this change cause the rule to produce more or fewer warnings?
More
How will the change be implemented? (New option, new default behavior, etc.)?
New option.
Please provide some example code that this change will affect:
const assert = require('assert');
const foo = `multi
line
template
strings
are
bad`;
assert(foo === 'multi line template strings are bad');
What does the rule currently do for this code?
It is happy.
What will the rule do after it’s changed?
It should report an error that using template strings that way is not a good idea.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:8
- Comments:14 (11 by maintainers)
Top Results From Across the Web
Prefer-template multiline · Issue #3507 · eslint/eslint - GitHub
Sometimes we break string in mulitple lines for lisibility like const a = "that string can get very" + `long ${someVar} and we...
Read more >Wrap long template literal line to multiline without creating a ...
I know I'm late to answer here, but the accepted answer still has the drawback of not allowing indents after the line break,...
Read more >prefer-template - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >How to Create Multi-Line String with Template Literals
It's super easy now to create multi-line strings with Template Literals in JavaScript. No more messy string line breaks. Yay, ES6!
Read more >Template literals (Template strings) - JavaScript | MDN
Template literals are literals delimited with backtick (`) characters, allowing for multi-line strings, string interpolation with embedded ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@LINKIWI that is why I suggested it as option and not as default.
Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.
Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.