chore(lint): prefer 'unknown' to 'any', fix lint warnings #18488
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
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.
|
isaacs
force-pushed
the
isaacschlueter/any-to-unknown
branch
2 times, most recently
from
ab3704a to
28f73dd
Compare
Lms24
reviewed
Dec 15, 2025
Member
Lms24
left a comment
Lms24
left a comment
There was a problem hiding this comment.
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.
isaacs
force-pushed
the
isaacschlueter/any-to-unknown
branch
from
28f73dd to
9fcac11
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
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.
isaacs
force-pushed
the
isaacschlueter/any-to-unknown
branch
from
9fcac11 to
5aadc4a
Compare
isaacs
commented
Dec 17, 2025
Member
Author
isaacs
left a comment
isaacs
left a comment
There was a problem hiding this comment.
Just replying/resolving comments
Lms24
approved these changes
Dec 18, 2025
Member
Lms24
left a comment
Lms24
left a comment
There was a problem hiding this comment.
Thanks for following up on my review!
chargome
approved these changes
Dec 18, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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)