Move eslint-plugin-prettier specific rules to its own file

[lydell]

arrow-body-style and prefer-arrow-callback cause trouble with eslint-plugin-prettier: https://github.com/prettier/eslint-config-prettier/tree/9444ee0b20f9af3ff364f62d6a9ab967ad673a9d#arrow-body-style-and-prefer-arrow-callback

Prettier de-emphasizes eslint-plugin-prettier these days, so I think we should remove those rules from "extends": "prettier" and move them to a separate file, just like we do for other plugins (react, flowtype, vue, etc). Those two rules are useful and I think it’s a shame that they’re turned off by default – in vain for many.

The difference this time is that all other plugin-specific files include only rules from the plugin in question. For eslint-plugin-prettier we’d only add arrow-body-style and prefer-arrow-callback, which are ESLint core rules, but I think it makes sense.

The question is what to call the config. So far the naming scheme for eslint-plugin-foo is "extends": "prettier/foo". I this case that would be:

{
  "extends": [
    "prettier",
    "prettier/prettier"
  ]
}

… which makes sense if you think about it, but is pretty confusing. Maybe the full plugin name is better in this case?

{
  "extends": [
    "prettier",
    "prettier/eslint-plugin-prettier"
  ]
}

Or, is it better if we only remove arrow-body-style and prefer-arrow-callback, and let eslint-plugin-prettier add those rules to their config instead? @BPScott any thoughts?

[BPScott]

Heya 👋

prettier/eslint-plugin-prettier sounds reasonable to me.

eslint-plugin-prettier doesn't really define configs, it only exposes plugin:prettier/recommended which just enables the prettier/prettier rule that the plugin provides and nothing more. It doesn't offer up any opinions on any other eslint rules - until now that's been the domain of eslint-config-prettier, and continuing with that mindset feels reasonable. I think I'd prefer this "editing of rules provided by eslint / other plugins" to remain eslint-config-prettier's responsibility.

The alternative wild suggestion: what if we merge eslint-plugin-prettier and eslint-config-prettier - a single codebase/package that can handle both - in that world a config that enables the prettier/prettier rule and disables arrow-body-style and prefer-arrow-callback might make sense? Is that worthwhile if the official prettier line is pushing folks away from the eslint plugin? Is there value in breaking the config/plugin symmetry that exists for the stylelint and tslint plugins/configs? Probably not 🤷

---

As a tangent, thanks for linking the updated version of https://prettier.io/docs/en/integrating-with-linters.html I hadn't spotted the rewrite. Something that's not that clear is what IS the recommended way of using both prettier and linters? That page starts out with "eslint-plugin-prettier etc are generally not recommended" and then says that prettier-eslint etc are slow which sounds not ideal. But it doesn't seem to say "we recommend you run prettier over everything, then run eslint over everything" or whatever.

[lydell]

I’m more and more starting to think this belongs to eslint-plugin-prettier. Those two rules have “nothing” to do with Prettier – only with eslint-plugin-prettier. So why should the be in a config about Prettier specifically?

I think it would be good to mention those two rules in the readme of eslint-plugin-prettier, since they’re an important caveat to know about. And adding them to plugin:prettier/recommended for convenience. Note: You say that plugin:prettier/recommended only enables the plugin rule, but it actually also enables the main file of eslint-config-prettier!

what IS the recommended way of using both prettier and linters

I’m not sure there’s much to say. Run them in any order, however you like. Re-run both if one of them changes anything.