prettier / eslint-config-prettier

Turns off all rules that are unnecessary or might conflict with Prettier.
MIT License
5.39k stars 255 forks source link

Add option to keep special rules enabled #225

Closed yfunk closed 2 years ago

yfunk commented 2 years ago

I'm building a shareable ESLint configuration, that is designed so you can layer different different configs on top of each other depending on the project type (similar example).

For a TypeScript React project that also happens to use Prettier you would do something like this

{
  "extends": [
    "my-config/typescript",
    "my-config/react",
    "my-config/prettier"
  ]
}

Amongst other things my-config/prettier also extends eslint-config-prettier to disable all rules that conflict with Prettier.

Since this includes the "special rules" that can be enabled in some cases it also overrides the curly rule I have set in my-config/typescript, even though it would work fine in this case. Explicitly specifying curly again in my-config/prettier would add another source of truth and pulling all the rules from this config into my own also doesn't seem that great of a solution.

I realize this is a very specific issue, but it still would be nice if there was an way to prevent eslint-config-prettier from overriding the special rules.

A non-breaking way to implement this could be doing the same thing as for the deprecated rules and adding a environment variable like ESLINT_CONFIG_PRETTIER_NO_SPECIAL.

Please let me know what you think about this suggestion, I'm open to create a PR for it 🙂

lydell commented 2 years ago

Hi! Here’s an idea: In my-config/prettier, instead of "extends": "prettier" you could do something like this:

module.exports = {
    rules: {
        ...Object.fromEntries(Object.entries(require("eslint-config-prettier").rules).filter(([, value]) => value !== 0))
    }
}

Would that work for you?

yfunk commented 2 years ago

That is definitely the better solution, thanks.

I even thought about doing it like this at first, but scrapped the idea because I forgot you can also require via the module name instead of a relative path 😅