-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
chore(lint): prefer 'unknown' to 'any', fix lint warnings #18488
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
base: develop
Are you sure you want to change the base?
Conversation
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
ab3704a to
28f73dd
Compare
Lms24
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for taking this on! Let's find a solution for the subtle breakage (see comments) but otherwise I think this is a really nice improvement and hopefully prevents us from using any without good reason in the future.
28f73dd to
9fcac11
Compare
size-limit report 📦
|
Explicitly enable `any` usage in typescript in: - `dev-packages`, since those are largely integration and E2E tests. (This is done with the addition of a `dev-packages/.eslintrc.js` file.) - `packages/*/test/`, since those are all tests. (This is done with a rule override added to the root `.eslintrc.js` file.) - Several one-off allowances, generally for vendored types from third party sources, and cases involving function type extension/overriding that TypeScript can't follow. (These are done with file/line overrides, explicit `as` casting, and adding type inference to the `isInstanceOf` method.) In other places (ie, in exported production code paths), replace `any` with `unknown`, and upgrade the `@typescript/no-explicit-any` lint rule to an error. This silences a lot of eslint warnings that were habitually ignored, and encourages us to not opt out of strict type safety in our exported code.
9fcac11 to
5aadc4a
Compare
isaacs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just replying/resolving comments
Explicitly enable
anyusage in typescript in:dev-packages, since those are largely integration and E2E tests. (This is done with the addition of adev-packages/.eslintrc.jsfile.)packages/*/test/, since those are all tests. (This is done with a rule override added to the root.eslintrc.jsfile.)ascasting, and adding type inference to theisInstanceOfmethod.)In other places (ie, in exported production code paths), replace
anywithunknown, and upgrade the@typescript/no-explicit-anylint rule to an error.This silences a lot of eslint warnings that were habitually ignored, and encourages us to not opt out of strict type safety in our exported code.
Closes #18489 (added automatically)