Rules that are conditionally type-aware #6423
bradzacher
announced in
RFCs
Replies: 2 comments 1 reply
-
|
I really would love to have a |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
It's something I've been thinking about considering there's the upcoming Reworking the rule to set it up as a way to easily onboard onto the option would be really useful for the community. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Something we've avoided in our project is rules that conditionally use type information.
The reason we have avoided them historically them is because:
A) in most cases there's no reason someone wouldnt want the extra safety from the type-information.
B) there's a lot of config complexity that gets added from this because the user needs to understand that "turning on config option X requires you to setup type-aware linting".
There's currently just one rule in our project that uses conditional type info
naming-conventionwhich uses types if and only if the user configures a selector that checks types. Which was only added because users wanted to be able to configure specific names for boolean-typed variables.I do wonder if we're unnecessarily tying our hands with this restriction. Whilst it's true that most cases you just want the type-aware checks and that without type-information a rule will be buggy or incomplete, there are cases where some users might want to opt-in to additional checks in specific circumstances or type-aware fixers.
Two quick examples off the top of my head:
explicit-function-return-type/explicit-module-boundary-typescould have a type-aware suggestion fixer added conditionally to help people annotate functions using the inferred return types, or even an autofixer for some simpler cases (like primitives -string,number,boolean,void).no-mixed-enumscould be AST-based by default, and have an option to be type-aware if the user's codebase uses enum merging or derived enums (both of which are rarer cases).prefer-optional-chainis currently AST based - but there are some edge cases with the boolean logicals that may refine a boolean type out that need type information to catch. It's a rarer case so it could be the case that this can be an opt-in.Now that we're a more mature project, I think we're getting to the point where our users are well-versed enough to understand the nuances of this style.
I'd be interested in us speccing this out a bit if people agree it's a good idea:
Beta Was this translation helpful? Give feedback.
All reactions