Community Feedback: Feature freeze on our naming and sorting stylistic rules #8091
Replies: 3 comments 8 replies
-
I don't think that removing our version of a rule in favour of an external one makes sense unless there is feature parity. For example you mention that Additionally whilst The same goes for How can we push people across to such a rule that likely won't cover their usecase? |
Beta Was this translation helpful? Give feedback.
-
In terms of separating these out into a new, separate package entirely (i.e. I don't believe that us washing our hands of them by moving them to an unowned / unmaintained 3rd-party package benefits anyone. At least living within our repo we can easily and will ensure they at least keep working forever as new TS features release. I'd be more than happy for us to add a big banner to each rule that says "these rules are feature frozen - we will fix bugs and support new TS features, but will not accept new feature requests" - i.e. the same stance as ESLint core has for its stylistic rules and would prefer that to shunting them out to a new repo. |
Beta Was this translation helpful? Give feedback.
-
I sent a few pings around and nobody had more things to add to the discussion. Filed #8792 to track doing it. Thanks all! 💙 |
Beta Was this translation helpful? Give feedback.
-
Right now, our Formatting docs reference ESLint's policy on preferring to avoid stylistic rules:
Yet we actively maintain a few rules that arguably fall purely within the prefer-to-avoid area:
@typescript-eslint/member-ordering
: the options are excessively complex, requiring many examples and nested descriptions of options in the docs@typescript-eslint/naming-convention
: same as member-ordering, and even has FAQs@typescript-eslint/sort-type-constituents
: supports basic group ordering but is not generally as comprehensive aseslint-plugin-perfectionist
Updated January 7th, 2024: I'd previously suggested we explicitly remove them from our package. But as @bradzacher pointed out below, there isn't enough active community activity to guarantee the rules will keep up-to-date with the latest TypeScript releases.
Updated proposal: how about we:
Original proposal kept here for posterity
I propose we move each of those lint rules to their own separate package, with the caveat that whichever package(s) take them on need to keep all of their existing features.
Advantages:
COMPLICATED_RULE_OPTIONS
)Disadvantages:
Thoughts, all?
Note that this discussion does not suggest we want to remove the existing
stylistic
orstylistic-type-checked
presets.@typescript-eslint/prefer-nullish-coalescing
and@typescript-eslint/prefer-string-starts-ends-with
are great at helping folks find better ways to write code.@typescript-eslint/array-type
that enforce adhering to one of <=3 common syntax forms have a strong benefit in aligning a codebase to a single style. This discussion is about rules that are highly unbounded in complexity and don't have definitive "pick one and practically always use that" solutions within a project.Beta Was this translation helpful? Give feedback.
All reactions