add support for @stylistic/eslint-plugin

[abrahamguo]

Since formatting rules have been deprecated from core ESLint and moved to @stylistic/eslint-plugin, this PR adds support for all the same rules in @stylistic/eslint-plugin. Despite its name, @stylistic/eslint-plugin still has rules that can be used with prettier:

• function-call-spacing
• lines-between-class-members
• padding-line-between-statements
• spaced-comment
• jsx-curly-brace-presence
• jsx-self-closing-comp
• jsx-sort-props
• lines-around-comment
• max-len
• no-confusing-arrow
• no-mixed-operators
• no-tabs
• quotes

This PR also updates package-lock.json to lockfileVersion: 3 (the version used by the current versions of npm) and ignores the .idea folder created by JetBrains IDEs.

[lydell]

Hi!

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

[abrahamguo]

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.

[lydell]

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?

[abrahamguo]

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.

[lydell]

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.

[abrahamguo]

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!

[abrahamguo]

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.