Name: eslint-config-prettier
Owner: Prettier
Description: Turns off all rules that are unnecessary or might conflict with prettier.
Created: 2017-01-29 20:07:58.0
Updated: 2018-01-18 15:42:46.0
Pushed: 2017-12-07 16:32:32.0
Size: 299
Language: JavaScript
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
Turns off all rules that are unnecessary or might conflict with Prettier.
This lets you use you favorite shareable config without letting its stylistic choices get in the way when using Prettier.
Tip: First, you might be interested in installing eslint-plugin-prettier. Follow the instructions over there. This is optional, though.
Install eslint-config-prettier:
m install --save-dev eslint-config-prettier
Then, add eslint-config-prettier to the “extends” array in your .eslintrc.*
file. Make sure to put it last, so it gets the chance to override other
configs.
xtends": [
"prettier"
A few ESLint plugins are supported as well:
Add extra exclusions for the plugins you use like so:
xtends": [
"prettier",
"prettier/flowtype",
"prettier/react",
"prettier/standard"
eslint-config-prettier also ships with a little CLI tool to help you check if your configuration contains any rules that are unnecessary or conflict with Prettier.
First, add a script for it to package.json:
cripts": {
"eslint-check": "eslint --print-config .eslintrc.js | eslint-config-prettier-check"
Then run npm run eslint-check.
(Swap out .eslintrc.js with the path to your config if needed.)
Exit codes:
xtends": [
"standard",
"plugin:flowtype/recommended",
"plugin:react/recommended",
"prettier",
"prettier/flowtype",
"prettier/react",
"prettier/standard"
lugins": [
"flowtype",
"react",
"prettier",
"standard"
arserOptions": {
"sourceType": "module",
"ecmaFeatures": {
"jsx": true
}
nv": {
"es6": true,
"node": true
ules": {
"prettier/prettier": "error"
There a few rules that eslint-config-prettier disables that actually can be enabled in some cases.
For maximum ease of use, the special rules are disabled by default. If you want them, you need to explicitly specify them in your ESLint config.
This rule requires certain options.
If a block (for example after if, else, for or while) contains only one
statement, JavaScript allows omitting the curly braces around that statement.
This rule enforces if or when those optional curly braces should be omitted.
If you use the "multi-line" or "multi-or-nest" option, the rule can conflict
with Prettier.
For example, the "multi-line" option allows this line:
cart.items && cart.items[0] && cart.items[0].quantity === 0) updateCart(cart);
However, Prettier might consider the line too long and turn it into the
following, which the "multi-line" option does not allow:
cart.items && cart.items[0] && cart.items[0].quantity === 0)
dateCart(cart);
If you like this rule, it can be used just fine with Prettier as long as you
don?t use the "multi-line" or "multi-or-nest" option.
Example configuration:
ules": {
"curly": ["error", "all"]
This rule can be used with certain options.
This rule requires empty lines before and/or after comments. Prettier preserves blank lines, with two exceptions:
By default, ESLint requires a blank line above the comment is this case:
result) {
comment */
turn result;
However, Prettier removes the blank line:
result) {
comment */
turn result;
If you like this rule, it can be used just fine with Prettier as long as you add some extra configuration to allow comments at the start and end of blocks, objects and arrays.
Example configuration:
ules": {
"lines-around-comment": [
"error",
{
"beforeBlockComment": true,
"afterBlockComment": true,
"beforeLineComment": true,
"afterLineComment": true,
"allowBlockStart": true,
"allowBlockEnd": true,
"allowObjectStart": true,
"allowObjectEnd": true,
"allowArrayStart": true,
"allowArrayEnd": true
}
]
This rule requires special attention when writing code.
Usually, Prettier takes care of following a maximum line length automatically. However, there are cases where Prettier can?t do anything, such as for long strings, regular expressions and comments. Those need to be split up by a human.
If you?d like to enforce an even stricter maximum line length policy than
Prettier can provide automatically, you can enable this rule. Just remember to
keep max-len?s options and Prettier?s printWidth option in sync.
Keep in mind that you might have to refactor code slightly if Prettier formats
lines in a way that the max-len rule does not approve of.
Example configuration:
ules": {
"max-len": ["error", {"code": 80, "ignoreUrls": true}]
This rule requires certain options.
For example, the rule could warn about this line:
x = a => 1 ? 2 : 3;
By default, ESLint suggests switching to an explicit return:
x = a => { return 1 ? 2 : 3; };
That causes no problems with Prettier.
With {allowParens: true}, adding parentheses is also considered a valid way to
avoid the arrow confusion:
x = a => (1 ? 2 : 3);
While Prettier keeps thoses parentheses, it removes them if the line is long enough to introduce a line break:
rpriseCalculator.prototype.calculateImportantNumbers = inputNumber =>
? 2 : 3;
If you like this rule, it can be used just fine with Prettier as long as the
allowParens option is off.
Example configuration:
ules": {
"no-confusing-arrow": "error"
This rule requires special attention when writing code.
This rule forbids mixing certain operators, such as && and ||.
For example, the rule could warn about this line:
foo = a + b * c;
The rule suggests adding parentheses, like this:
foo = a + (b * c);
However, Prettier removes many ?unnecessary? parentheses, turning it back to:
foo = a + b * c;
If you want to use this rule with Prettier, you need to split the expression into another variable:
bar = b * c;
foo = a + bar;
Keep in mind that Prettier prints some ?unnecessary? parentheses, though:
foo = (a && b) || c;
Example configuration:
ules": {
"no-mixed-operators": "error"
This rule requires certain Prettier options.
This rule disallows the use of tab characters at all. It can be used just fine with Prettier as long as you don?t configure Prettier to indent using tabs.
Example configuration:
ules": {
"no-tabs": "error"
This rule requires special attention when writing code.
This rule disallows confusing multiline expressions where a newline looks like it is ending a statement, but is not.
For example, the rule could warn about this:
hello = "world"
2, 3].forEach(addNumber)
Prettier usually formats this in a way that makes it obvious that a semicolon was missing:
hello = "world"[(1, 2, 3)].forEach(addNumber);
However, there are cases where Prettier breaks things into several lines such
that the no-unexpected-multiline conflicts.
t value = text.trim().split("\n")[position].toLowerCase();
Prettier breaks it up into several lines, though, causing a conflict:
t value = text
rim()
plit("\n")
osition].toLowerCase();
If you like this rule, it can usually be used with Prettier without problems, but occasionally you might need to either temporarily disable the rule or refactor your code.
t value = text
rim()
plit("\n")
eslint-disable-next-line no-unexpected-multiline
osition].toLowerCase();
r:
t lines = text.trim().split("\n");
t value = lines[position].toLowerCase();
Note: If you do enable this rule, you have to run ESLint and Prettier as two separate steps (and ESLint first) in order to get any value out of it. Otherwise Prettier might reformat your code in such a way that ESLint never gets a chance to report anything (as seen in the first example).
Example configuration:
ules": {
"no-unexpected-multiline": "error"
This rule requires certain options.
If you?d like to enforce the use of backticks rather than single or double
quotes for strings, you can enable this rule. Otherwise, there?s no need to.
Just remember to enable the "backtick" option!
Example configuration:
ules": {
"quotes": ["error", "backtick"]
eslint-config-prettier has been tested with:
Have new rules been added since those versions? Have we missed any rules? Is there a plugin you would like to see exclusions for? Open an issue or a pull request!
If you?d like to add support for eslint-plugin-foobar, this is how you?d go about it:
First, create foobar.js:
strict";
le.exports = {
les: {
"foobar/some-rule": "off"
Then, create test-lint/foobar.js:
slint-disable quotes */
strict";
rettier does not want spaces before the parentheses, but
slint-config-foobar wants one.
ole.log ();
test-lint/foobar.js must fail when used with eslint-plugin-foobar and
eslint-plugin-prettier at the same time ? until "prettier/foobar" is added to
the “extends” property of an ESLint config.
Finally, you need to mention the plugin in several places:
"foobar.js" to the “files” field in package.json.package.json..eslintrc.base.js.README.md.When you?re done, run npm test to verify that you got it all right. It runs
several other npm scripts:
"test:lint" makes sure that the files in test-lint/ pass ESLint when
the exclusions from eslint-config-prettier are used. It also lints the code of
eslint-config-prettier itself."test:lint-verify-fail" is run by a test in test/lint-verify-fail.js."test:lint-rules" is run by a test in test/rules.js."test:ava" runs unit tests that check a number of things:"test:cli-sanity" is a sanity check for the CLI.MIT.