Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[no-inferrable-types] Add an option to enable it for any values #907

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
Closed
ark120202 opened this issue Aug 26, 2019 · 7 comments
Closed

[no-inferrable-types] Add an option to enable it for any values #907

ark120202 opened this issue Aug 26, 2019 · 7 comments
Labels
enhancement New feature or request package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@ark120202
Copy link

Currently this rule warns only when rhs is either a literal or an associated global constructor function. I'd like to have an option to warn about any cases when type annotation doesn't change variable type.

type MyType = { foo: string };
const getString = () => 'foo';

const valid1: string | undefined = getString();
const valid2: MyType = { foo: 'bar' };

const invalid1: string = getString();
const invalid2: string | string = getString();
const invalid3: string | undefined = Math.random() > 0.5 ? getString() : undefined;
class Test { static invalid4: Test = new Test(); }
const invalid5: MyType = null! as MyType;

I've done a bit of testing and apparently equal types have the same reference (even in the invalid2 case), so something like typeChecker.getTypeAtLocation(typeAnnotation) === typeChecker.getTypeAtLocation(initializer) can be enough to check this.
@ark120202 ark120202 added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Aug 26, 2019
@bradzacher bradzacher added enhancement: plugin rule option New rule option for an existing eslint-plugin rule awaiting response Issues waiting for a reply from the OP or another party and removed triage Waiting for team members to take a look enhancement: plugin rule option New rule option for an existing eslint-plugin rule labels Aug 26, 2019
@bradzacher
Copy link
Member

Doesn't no-unnecessary-type-assertion handle this case?

no-inferrrable-types currently doesn't use the type checker, so adding this would be a breaking change.

@ark120202
Copy link
Author

No, none of the cases listed there are handled by no-unnecessary-type-assertion.

Wouldn't it be possible to make it require type checker only when a new option is enabled?

@bradzacher
Copy link
Member

bradzacher commented Aug 26, 2019 •
edited
Loading

I don't think this belongs in no-inferrable-types, because that's more about stopping people from providing explicit types for primitive values.
I guess the naming's kinda bad, but the idea is that you can easily infer the type from a primitive value, even without an IDE, so strictly typing it is literally useless.

In your case, functions aren't easily identifiable because you need to inspect their return type.
So I'd probably lean toward this belong in nuta, because strictly typing a variable/property/argument declaration is a type assertion on the value.

@ark120202
Copy link
Author

I guess the naming's kinda bad, but the idea is that you can easily infer the type from a primitive value, even without an IDE, so strictly typing it is literally useless.

Makes sense, would it worth it to rename it then? Maybe to something like obvious or apparent? Also TypeScript documentation link doesn't seem really related in that case.

So I'd probably lean toward this belong in nuta, because strictly typing a variable/property/argument declaration is a type assertion on the value.

Type assertion has a strict definition in typescript docs, so I think that may make it a bit confusing. Maybe it would make sense to rename it to no-unnecessary-types that would handle both type assertions and type annotations?

@bradzacher
Copy link
Member

Mmmm I always think of it as "explicit type assertion" (as foo) vs "implicit type assertion" (x: foo = ...). But yeah it's not correct to say that.

Flip flopping a bit, sorry, but yeah if we're being correct with the terminology, I guess it probably does just belong in no-inferrable-types.

Thinking about it more nuta already does quite a bit, and expanding its scope to type annotations might make it too complex / hard to maintain / etc.

TBH nit could be rewritten to just use the type checker - I mean, in its current state, it's pretty darn complex considering that all it's doing is comparing literal values to type annotations.

@bradzacher bradzacher added enhancement New feature or request and removed awaiting response Issues waiting for a reply from the OP or another party labels Aug 29, 2019
@bradzacher bradzacher mentioned this issue Aug 29, 2019
Closed
@glen-84
Copy link
Contributor

glen-84 commented Sep 8, 2019

Is this a duplicate of #295?

@bradzacher
Copy link
Member

actually, I think it is - good catch.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement New feature or request package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@glen-84 @bradzacher @ark120202