chore(lint): prefer 'unknown' to 'any', fix lint warnings #18488
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.
|
isaacs
force-pushed
the
isaacschlueter/any-to-unknown
branch
2 times, most recently
from
ab3704a to
28f73dd
Compare
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.
| // Based on Kamil Ogórek's work on: | ||
| // https://github.com/supabase-community/sentry-integration-js | ||
|
|
||
| /* eslint-disable @typescript-eslint/no-explicit-any */ |
There was a problem hiding this comment.
l: Should we think about splitting this file up into type definitons and our functionality? My thinking is for type definitions the file-wide explicit any disabling makes sense but it could let stuff slip through in the functions we export. WDYT?
(feel free to disregad, there might be a good reason I'm missing to disable it also for the exported functions)
| */ | ||
| export interface ExtendedError extends Error { | ||
| [key: string]: any; | ||
| [key: string]: unknown; |
There was a problem hiding this comment.
m: This type is publicly exported. I think this is a (subtle) breaking change, right?
Update: I found a few more changes below with the same issue. I think in most cases the affected types are only supposed to be used on objects users would pass to the SDK (in which case, it's on us to do more through checking). But nothing holds them back from also working with said objects in which case TS could break their builds after updating. I'm leaning towards avoiding this kind of subtle breakage (but definitely fixing it in v11) but also happy to be convinced otherwise :D
WDYT?
| */ | ||
| export interface ExtractedNodeRequestData { | ||
| [key: string]: any; | ||
| [key: string]: unknown; |
There was a problem hiding this comment.
m: this is also exported, so same question as above
| */ | ||
| export interface CustomSamplingContext { | ||
| [key: string]: any; | ||
| [key: string]: unknown; |
There was a problem hiding this comment.
m: this is also exported, so same question as above
| showEmail={options.showEmail || options.isEmailRequired} | ||
| defaultName={(userKey && user?.[userKey.name]) || ''} | ||
| defaultEmail={(userKey && user?.[userKey.email]) || ''} | ||
| defaultName={String((userKey && user?.[userKey.name]) || '')} |
There was a problem hiding this comment.
I guess this comes from the type change in User. Wondering if this would also apply to anyone outside of our SDK code. See comment above
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
28f73dd to
9fcac11
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| actionTransformer: (action: string) => any; | ||
| stateTransformer: (state: Record<string, unknown>) => any; | ||
| actionTransformer: (action: string) => unknown; | ||
| stateTransformer: (state: Record<string, unknown>) => Record<string, unknown>; |
There was a problem hiding this comment.
Bug: stateTransformer return type doesn't match runtime null handling (Bugbot Rules)
The stateTransformer return type changed from any to Record<string, unknown>, but the runtime code at line 101 explicitly checks if (typeof allStates !== 'undefined' && allStates !== null), indicating that returning null was a valid use case to disable state tracking. Users who previously passed stateTransformer: () => null will now get TypeScript errors even though the runtime still handles this case. This is a breaking change to a public API (createSentryPiniaPlugin accepts this option) that could break existing user code. Flagging per the review rules about public API changes.
| vars?: { [key: string]: unknown }; | ||
| debug_id?: string; | ||
| module_metadata?: any; | ||
| module_metadata?: unknown; |
There was a problem hiding this comment.
Bug: StackFrame type change is a public breaking change (Bugbot Rules)
The StackFrame interface is publicly exported from @sentry/core (verified in index.ts line 453). The vars property changed from { [key: string]: any } to { [key: string]: unknown } and module_metadata changed from any to unknown. This is a breaking change for users who access these properties without type narrowing, as unknown requires explicit type checks or assertions unlike any. This change wasn't flagged in the PR discussion unlike similar changes to User, ExtendedError, etc. Flagging per the review rules about public API changes.
| * @returns A boolean representing the result. | ||
| */ | ||
| export function isInstanceOf(wat: any, base: any): boolean { | ||
| export function isInstanceOf<T>(wat: unknown, base: { new (...args: any[]): T }): wat is T { |
There was a problem hiding this comment.
Bug: isInstanceOf public API signature is breaking change (Bugbot Rules)
The isInstanceOf function is publicly exported from @sentry/core and its signature changed from (wat: any, base: any): boolean to <T>(wat: unknown, base: { new (...args: any[]): T }): wat is T. This restricts the base parameter to only accept constructor types, whereas previously it accepted any. Users who called isInstanceOf(someValue, nonConstructorValue) will now get TypeScript errors, even though the runtime behavior is unchanged (the try-catch handles non-constructors). This wasn't flagged in the PR discussion. Flagging per the review rules about public API signature changes.
size-limit report 📦
|
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)