Skip to content

feat(eslint-plugin): [no-unsafe-argument] add rule #3256

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Apr 2, 2021
Merged

feat(eslint-plugin): [no-unsafe-argument] add rule #3256

merged 1 commit into from
Apr 2, 2021

Conversation

bradzacher
Copy link
Member

Fixes #791

This adds a new rule which just checks the passing of arguments.
This case is a lot more complex than most cases due to spread arguments.

@bradzacher
feat(eslint-plugin): [no-unsafe-argument] add rule
a086fa1 
Fixes #791

This adds a new rule which just checks the passing of arguments.
This case is a lot more complex than most cases due to spread arguments.
@bradzacher bradzacher added the enhancement: new plugin rule New rule request for eslint-plugin label Apr 1, 2021
@typescript-eslint
Copy link
Contributor

Thanks for the PR, @bradzacher!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

@codecov
Copy link

codecov bot commented Apr 1, 2021

Codecov Report

Merging #3256 (a086fa1) into master (62dfcc6) will decrease coverage by 0.07%.
The diff coverage is 81.15%.

@@            Coverage Diff             @@
##           master    #3256      +/-   ##
==========================================
- Coverage   92.91%   92.84%   -0.08%     
==========================================
  Files         316      317       +1     
  Lines       10854    10923      +69     
  Branches     3069     3086      +17     
==========================================
+ Hits        10085    10141      +56     
- Misses        342      348       +6     
- Partials      427      434       +7
Flag Coverage Δ
unittest 92.84% <81.15%> (-0.08%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
packages/eslint-plugin/src/configs/all.ts 100.00% <ø> (ø)
...ages/eslint-plugin/src/rules/no-unsafe-argument.ts 81.15% <81.15%> (ø)

@bradzacher bradzacher merged commit b1aa7dc into master Apr 2, 2021
@bradzacher bradzacher deleted the no-unsafe-argument branch April 2, 2021 20:19
@G-Rath
Copy link
Contributor

G-Rath commented Apr 5, 2021 •
edited
Loading

@bradzacher do you think this could be another one worth extending in eslint-plugin-jest, to have it ignore the any of expect async matchers?

i.e

expect(mockMessageReactor.prototype.react).toHaveBeenCalledWith(
  message,
  expect.arrayContaining<ReactionAction>([
    ['heavy_multiplication_x', true]
  ])
);

I know I can satisfy this by casting to unknown (or stronger), but in this context such a cast is typically very meaningless.

In saying that, I am casting for properties due to no-unsafe-assignment:

expect(mockSlackReactionsApi.remove).toHaveBeenCalledWith({
  name: expect.any(String) as string,
  timestamp: '1',
  channel: '#my-channel'
});

Curious on if you have any opinions on if this is something extending :)

@bradzacher
Copy link
Member Author

this rule checks arguments using out isUnsafeAssignment function.

typescript-eslint/packages/eslint-plugin/src/util/types.ts

Lines 418 to 471 in cb22561

export function isUnsafeAssignment(
type: ts.Type,
receiver: ts.Type,
checker: ts.TypeChecker,
): false | { sender: ts.Type; receiver: ts.Type } {
if (isTypeAnyType(type)) {
// Allow assignment of any ==> unknown.
if (isTypeUnknownType(receiver)) {
return false;
}
if (!isTypeAnyType(receiver)) {
return { sender: type, receiver };
}
}
if (isTypeReference(type) && isTypeReference(receiver)) {
// TODO - figure out how to handle cases like this,
// where the types are assignable, but not the same type
/*
function foo(): ReadonlySet<number> { return new Set<any>(); }
// and
type Test<T> = { prop: T }
type Test2 = { prop: string }
declare const a: Test<any>;
const b: Test2 = a;
*/
if (type.target !== receiver.target) {
// if the type references are different, assume safe, as we won't know how to compare the two types
// the generic positions might not be equivalent for both types
return false;
}
const typeArguments = type.typeArguments ?? [];
const receiverTypeArguments = receiver.typeArguments ?? [];
for (let i = 0; i < typeArguments.length; i += 1) {
const arg = typeArguments[i];
const receiverArg = receiverTypeArguments[i];
const unsafe = isUnsafeAssignment(arg, receiverArg, checker);
if (unsafe) {
return { sender: type, receiver };
}
}
return false;
}
return false;
}

Which will allow assignments of any to either any or unknown.
So as long as the jest expect functions are typed as receiving any or unknown, then it should just work.

@bradzacher
Copy link
Member Author

But it looks like there is a bug in the rule.

The jest function is typed as:

declare function toHaveBeenCalledWith<E extends any[]>(...params: E): void;

So at typecheck type, when called with toHaveBeenCalledWith(1 as any), the type of params isn't any[], it's [any].. which isn't handled right now

@G-Rath
Copy link
Contributor

G-Rath commented Apr 5, 2021

So as long as the jest expect functions are typed as receiving any or unknown, then it should just work.

which (if I remember and understand everything correctly) they're not - they're typed to receive any[] (where appropriate).

So:

expect(captureExceptionSpy).toHaveBeenCalledWith(expect.any(Error));

Gets

ESLint: Unsafe argument of type any assigned to a parameter of type [any].(@typescript-eslint/no-unsafe-argument)

(that could be what you mean by [any] not being handled right now).

@Obi-Dann Obi-Dann mentioned this pull request Apr 10, 2021
Draft
@github-actions github-actions bot mentioned this pull request Apr 12, 2021
Merged
@fabb
Copy link

fabb commented Apr 20, 2021

shouldn't the new rule be added to the recommended-requiring-type-checking preset?

@bradzacher
Copy link
Member Author

bradzacher commented Apr 20, 2021 •
edited
Loading

It will, but changes to the recommended sets is a breaking change.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
enhancement: new plugin rule New rule request for eslint-plugin
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

New set of rules: no-unsafe-*
3 participants
@bradzacher @G-Rath @fabb