-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Request: Consider also moving slightly-more-than-formatting rules out of core #17681
Comments
We already decided to keep What other rules are you referring to? |
I'm proposing that be reconsidered. Going through the blog post and rules list, the list I'm proposing for this issue is:
To be honest, I was busy over the last month and wasn't able to find time to think deeply and comment in #17522. I wish I had posted this issue as a comment >2 weeks ago. |
The decision on I don't have a strong opinion about the other two, so I'd be fine with deprecating them. Do Prettier and/or dprint handle those? |
This comment was marked as duplicate.
This comment was marked as duplicate.
@MrHBS @meerhimmel I already answered about |
Another one that is purely stylistic is |
Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update. |
@antfu do you have a list of additional rules that you think would make more sense to be in eslint-stylistic than the core? |
For ESLint Stylistic we don't have a strong opinion on what rules to include, we generally take what ESLint/ts-eslint deprecated, as long as they fit in the category of "Stylistic". Personally, I agree with Josh at #17681 (comment) |
Crosslinking typescript-eslint/typescript-eslint#8102 and eslint-stylistic/eslint-stylistic#238 as it is stuck in this weird limbo of "Stylistic, but still in core, so no one touches it" |
Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update. |
Ping @eslint/eslint-team. What are the next steps here? |
Where we're at here is deciding whether we want to deprecate these two rules:
I'm fine with that, as they are just enforcing preferences. @mdjermanovic @fasttime what do you think? |
I think it makes sense to move these rules to |
TSC Summary: This issue seeks to deprecate two additional rules, TSC Question: Shall we do so? |
Per 2024-04-04 TSC meeting, we've decided to deprecate these two rules and coordinate with |
Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update. |
…18435) * feat: deprecate multiline-comment-style & line-comment-position fixes #17681 * fix: add @deprecated tag * fix: deprecated tags * docs: add rule links to the stylistic plugin
ESLint version
8.52.0
What problem do you want to solve?
(Moving #17522 (comment) here) Following up on rules such as
curly
andpadding-line-between-statements
(eslint-stylistic/eslint-stylistic#26 -> eslint-stylistic/eslint-stylistic#26 (comment)): there are some core rules that aren't quite covered by some or all formatters, but are still within the realm of what eslint-stylistic would cover. Could we also move those rules out of core, with the intent to move them to eslint-stylistic?What do you think is the correct solution?
Rules such as
curly
that are at or just above the formatting level suffer from many of the maintainability drawbacks mentioned in #17522. The eslint-stylistic project is intentionally named stylistic rather than formatting so that it can encompass more than just formatting rules. See eslint-stylistic/eslint-stylistic#26.Participation
Additional comments
Sorry for raising this so late after the initial discussion!
The text was updated successfully, but these errors were encountered: