Thanks to visit codestin.com
Credit goes to github.com

Skip to content

docs: warn against progressive type enhancement in rules #7440

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.

Sign up for GitHub

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

Merged
merged 4 commits into from
Oct 19, 2023
Merged

docs: warn against progressive type enhancement in rules #7440

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1ebefdf
docs: warn against progressive type enhancement in rules
JoshuaKGoldberg Aug 7, 2023
1fad50d
Apply suggestions from code review
JoshuaKGoldberg Sep 8, 2023
4185f41
Two versions
JoshuaKGoldberg Sep 11, 2023
ab7eadd
Options gating
JoshuaKGoldberg Sep 11, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions docs/developers/Custom_Rules.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -272,6 +272,13 @@ Rules can retrieve their full backing TypeScript type checker with `services.pro
This can be necessary for TypeScript APIs not wrapped by the parser services.
:::

:::caution
We recommend against changing rule logic based solely on whether `services.program` exists.
In our experience, users are generally surprised when rules behave differently with or without type information.
Additionally, if they misconfigure their ESLint config, they may not realize why the rule started behaving differently.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds vague. Maybe a specific case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm yeah good point. Agreed.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as possible solution we could recommend to create 2 separate rules one with type-info and one without

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it! Added :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also gating it behind options is okay, I think.
That way you still have that hard point of a user explicitly opting in to the type-awareness and thus the rule can explicitly crash if it's not provided.

naming-convention does this (the only rule we have that does) for the type-based enforcement of names.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This actually is very relevant to vitest-dev/eslint-plugin-vitest#251. Nice.

Consider either gating type checking behind an explicit option for the rule or creating two versions of the rule instead.
:::

## Testing

`@typescript-eslint/rule-tester` exports a `RuleTester` with a similar API to the built-in ESLint `RuleTester`.
Expand Down