Skip to content
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

Cleanup warning noise from eslint #20684

Merged
merged 1 commit into from
Apr 23, 2024
Merged

Cleanup warning noise from eslint #20684

merged 1 commit into from
Apr 23, 2024

Conversation

ef4
Copy link
Contributor

@ef4 ef4 commented Apr 22, 2024

We inherit several default rules at the "warn" level. IMO it's useless to leave rules at "warn", because people just ignore them and live with an increasing amount of noise.

As evidence I cite the 716 warnings that one must currently scroll through to find an actual lint failure.

This change turns unused-vars into errors, while enabling underscore-based exceptions that follow typescript's own defaults for its internal unused-vars rule.

And it disables no-explicit-any and no-non-null-assertion. These features are in the language for a reason. Idiomatic javascript that gains types after-the-fact needs these features, which is why we need them all over the place. If somebody else thinks these rules are good, I'm all in favor of enabling them as errors so they actually get followed, but then you've gotta do the project to refactor all the types to not need them so much.

We inherit several default rules at the "warn" level. IMO it's useless to leave rules at "warn", because people just ignore them and live with an increasing amount of noise.

As evidence I cite the 716 warnings that one must currently scroll through to find an actual lint failure.

This change turns unused-vars into errors, while enabling underscore-based exceptions that follow typescript's own defaults for its internal unused-vars rule.

And it disables no-explicit-any and no-non-null-assertion. These features are in the language for a reason. Idiomatic javascript that gains types after-the-fact needs these features, which is why we need them all over the place. If somebody else thinks these rules are good, I'm all in favor of enabling them **as errors** so they actually get followed, but then you've gotta do the project to refactor all the types to not need them so much.
@ef4 ef4 merged commit 1c557eb into main Apr 23, 2024
22 checks passed
@ef4 ef4 deleted the adjust-eslint branch April 23, 2024 12:46
@ef4 ef4 added the internal label Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants