Merge `eslint-config-prettier` into `eslint-plugin-prettier`?

[bmish]

Do eslint-config-prettier and eslint-plugin-prettier need to be separate plugins? Or can they be consolidated / merged / combined into a single plugin (eslint-plugin-prettier)? If there's a legit need for them to stay separate, please let me know.

Here’s are some thoughts on why it could make sense to combine them:

1. Realistically, isn't nearly everyone using them together?
2. Even if a small percentage of users only need one of them, there wouldn’t be any downside to them of a combined plugin, would there?
3. The size of both packages is pretty minimal (18KB for the config 52KB for the plugin). I don’t think the combined size would bother anyone, especially given that these are dev dependencies.
4. ESLint plugins frequently include both rules and configs. Most ESLint plugins do not split out their config/rules into separate plugins.
5. I’ve seen other instances of separated configs/plugins that eventually were combined when people realized it was easier for everyone that way.
6. A single plugin would make it easier for most users to get setup with prettier, which currently requires installing 3 dependencies (prettier, eslint-plugin-prettier, eslint-config-prettier).
7. Presumably, a lot of bug reports come from users forgetting to install the config or the plugin?

Again, please me know if there would be serious downsides to combining them.

[lydell]

Hi! Have you read https://prettier.io/docs/en/integrating-with-linters.html?

[bmish]

Thanks for sharing. So it sounds like you're suggesting there are benefits to running prettier on its own without relying on ESLint to run it, especially in regards to performance. That's helpful to know.

Now it still doesn't seem like that would preclude having a combined eslint-plugin-prettier which could handle both situations (running prettier with or without ESLint). Perhaps you could speak more about the motivation there? Is it that you're actually trying to discourage people from using prettier with ESLint, or just trying to make prettier vs. ESLint more distinct workflows?

[lydell]

To me it feels weird merging this repo with a – IMO – semi deprecated one. I can recommend eslint-config-prettier to any Prettier + ESLint user – there’s no downside to it – but I can’t recommend eslint-plugin-prettier to everyone, since it has problems you need to decide if you like or not. If they are merged, I’d have to recommend people to “use the config part, but be careful not to use the plugin part (unless you know what you’re doing)”. It would lure people into non-optimal Prettier setups.

I also like minimal packages a lot, and would not appreciate the package size increase. I don’t think people who don’t use the plugin should be forced to install dead code. Which are a lot of people: At the time of writing eslint-config-prettier had 9.3 million weekly downloads, while eslint-plugin-prettier had 7.4 million.

If you want to know the history, the plugin and the config were developed completely independently by different people. Originally the weren’t even in the prettier org. So it wasn’t like someone just decided that they should have different repos for whatever reason.

The plugin and the config are very different and have nothing to do with each other, other than being related to Prettier. Many ESLint plugins ship a bunch of rules and configs to enable some of them. But eslint-config-prettier is different – it just disables others’ rules.

[lydell]

Closing, since the discussion stopped.