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.
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
[no-inferrable-types][typedef] Rules clash in 'all' config #902
Comments
@bradzacher, In order to fix this issue, need to change |
Technically in this case, it is actually a bug in But it also seems like an intractable problem to solve, as the two rules are at-odds in this, and pretty much every case. This might be solvable by adding an option to |
We've just had a round of rule deprecations in v2.0.0, but it sounds like It may require changing the options for For example, something like this might work? Correct code/* @typescript-eslint/typedef: ['error', { variableDeclaration: 'always' }]` */
const a: string = 'a string';
/* @typescript-eslint/typedef: ['error', { variableDeclaration: 'if-not-inferred' }]` */
const a = 'a string'; Incorrect code/* @typescript-eslint/typedef: ['error', { variableDeclaration: 'always' }]` */
const a = 'a string';
/* @typescript-eslint/typedef: ['error', { variableDeclaration: 'if-not-inferred' }]` */
const a: string = 'a string'; Just a thought. |
(reopening because the bug is fixed, but there is a separate issue at hand here) |
I'm not sure if Originally the TSLint rule was there to cover a bunch of holes in the coverage of // yes, these used to be allowed by noImplicitAny
interface Foo {
prop;
}
class Foo {
prop;
} With each version of TS, they have improved the coverage of There's now only one case (that I know of) that isn't caught by let foo; I think this is entirely intentional though (as silly as it looks). IMO - I see our version of I think |
class Foo {
foo? = 'str'
} Appears to have no errors (with strictest options) and infers the same |
that is weird syntax that I didn't even know existed! I think it's probably better to not to treat it as inferrable, as we'd have to create a special fixer specifically for this case (as I don't think this syntax is valid in any other location). |
This issue reminds me of palantir/tslint#711. IMO, |
I don't agree because Additionally, |
The same problem happens for default arguments in functions in all config expected a type annotation - eslint(@typescript-eslint/typedef) const myFunction = (param1 = false) {
} Type boolean trivially inferred from a boolean literal, remove type annotation.eslint(@typescript-eslint/no-inferrable-types) const myFunction = (param1: boolean = false) {
} |
What about using the function |
this shouldn't happen any more as typedef no longer has any options on by default |
True, this is not a problem anymore. |
then how would i specify that i want to have typedef except if it is infered ? |
Seems to have a clash between those rules in all config. Am I missing something to make this case pass?
Repro
This will result in
error Type string trivially inferred from a string literal, remove type annotation @typescript-eslint/no-inferrable-types
This will result in
error expected who to have a type annotation @typescript-eslint/typedef
Versions
@typescript-eslint/eslint-plugin
2.0.0
@typescript-eslint/parser
2.0.0
TypeScript
3.5.3
ESLint
6.1.0
The text was updated successfully, but these errors were encountered: