-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Open
Labels
accepting prsGo ahead, send a pull request that resolves this issueGo ahead, send a pull request that resolves this issueenhancement: plugin rule optionNew rule option for an existing eslint-plugin ruleNew rule option for an existing eslint-plugin rulepackage: eslint-pluginIssues related to @typescript-eslint/eslint-pluginIssues related to @typescript-eslint/eslint-plugin
Description
Before You File a Proposal Please Confirm You Have Done The Following...
- I have searched for related issues and found none that match my proposal.
- I have searched the current rule list and found no rules that match my proposal.
- I have read the FAQ and my problem is not listed.
My proposal is suitable for this project
- I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).
Link to the rule's documentation
https://typescript-eslint.io/rules/no-unsafe-argument
Description
Currently no-unsafe-argument doesn't catch object arguments with nested any types. For example:
// Imagine this is a value received from a library.
declare const fromLib: { foo: any };
// Imagine this is a function defined in user-land.
declare const fn: (x: { foo: number }) => string;
// This is unsafe due to the inner `any` type.
fn(fromLib);A real world example of where this comes up is React Router's useLocation hook, which returns a Location object where the state property has type any.
Would it make sense to extend this lint rule to check for anys nested inside object types?
Fail
// Imagine this is a value received from a library.
declare const fromLib: { foo: any };
// Imagine this is a function defined in user-land.
declare const fn: (x: { foo: number }) => string;
// This is unsafe due to the inner `any` type.
fn(fromLib);Pass
declare const fromLib: { foo: number };
declare const fn: (x: { foo: number }) => string;
fn(fromLib);Additional Info
No response
Metadata
Metadata
Assignees
Labels
accepting prsGo ahead, send a pull request that resolves this issueGo ahead, send a pull request that resolves this issueenhancement: plugin rule optionNew rule option for an existing eslint-plugin ruleNew rule option for an existing eslint-plugin rulepackage: eslint-pluginIssues related to @typescript-eslint/eslint-pluginIssues related to @typescript-eslint/eslint-plugin