Hi!

Can you describe what your motivating use case is for this?

Sure thing! I'd like to be able to use the stylistic rules from @stylistic/eslint-plugin that are unaffected by Prettier (the specific rules are listed above), while still using this to turn off all rules that conflict with Prettier.

I think this makes sense from a comprehensive purpose — since eslint-config-prettier disables rules from eslint, @typescript-eslint, and eslint-plugin-react, and those rules have been moved (in eslint) or copied (in @typescript-eslint and eslint-plugin-react) to @stylistic/eslint-plugin, I think it makes sense that eslint-config-prettier is able to disable those same rules, no matter which package they come from.

Thanks! Just so that I understand what you’re doing correctly: Why don’t you enable just the rules from @stylistic/eslint-plugin that don’t conflict? Is this PR about having a place that lists the ones that do conflict, so people can know which ones are safe?

Great question! Two answers:

1. Yes, I think it'd be good to have an exhaustive list of the ones that do conflict, especially since the list is the same as what's in eslint, @typescript-eslint, and react.
2. My preferred way to discover rules when I begin using a new ESLint plugin is to turn on all rules provided by that plugin, then turn off ones that I disagree with, as they report issues in my code. By adding the @stylistic/eslint-plugin rules here, I am able to do the same thing for this plugin - turn on all rules, then rest assured that all rules that conflict with Prettier, will be turned off.

Aha, turning on all rules from a plugin and then disabling the ones that conflict – I can see that being a thing. 👍

Then I have a request: I would rather have all the @stylistic stuff duplicated than using that helper function, so we can handle deprecations correctly. I don’t mind the duplication. They are forked rules after all, and may change over time, while the rules they replace are basically frozen in time.

Totally fair, makes sense! I anticipated you might comment about that, since it was a very different style than what was in that file before.
I'll go ahead and do that in a bit!

I've mostly completed this — I just need to figure out how to get the tests working properly. It's very confusing because there are five different stylistic plugins — js, ts, tsx, plus, and all, which contains all of the other 4.

Any news? Would love to have this built-in

I will see if I can get this finished up!

🦋 Changeset detected

Latest commit: c4651b1

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Any update on the merge?

No updates, I will probably need someone else to take this over. The logic is done, I simply need help finishing up the unit tests.

Further complicating this is that ESLint Stylistic plans to merge their various packages (default, JavaScript, TypeScript, JSX) into one.

For those wanting this and banging their heads against the unit tests, note:

the testing setup is overdue some simplification

#275 (comment)

(I’m not involved in the project anymore, I just occasionally read notifications on the repo.)

For somebody who just wants to update such packages once in a while and seeing a breaking change version bump while not wanting to dive deep into the matter, I would appreciate a little documentation of what the breaking change is and whether there are any migration steps needed if I want to bump my eslint-config-prettier version from 9.1.0 to 10.0.1?

v10 should be compatible mostly, but it adds @stylistic/* support, I released it as major because not everyone is using @stylistic/*, there could be a tiny chance to break.

Additionally, we migrated the releasing tool to changesets and leave package.json and files structure untouched, so the file structure is different now.

Previous:

Now: