This repository was archived by the owner on Mar 25, 2021. It is now read-only.
This repository was archived by the owner on Mar 25, 2021. It is now read-only.
Parenthesized simple types are not fixed correctly when using array-type array-simple #4844
Closed
Description
Bug Report
- TSLint version: 5.19.0
- TypeScript version: 3.5.3
- Running TSLint via: CLI
Reproduction using TSLint Playground
TypeScript code being linted
type A = (number)[];
with tslint.json
configuration:
{
"extends": ["tslint:recommended"],
"rules": {
"array-type": [true, "array-simple"]
}
}
Actual behavior
- Running
tslint --fix
, "fixes"(number)[]
toArray<number>
. This raises an error because of the"array-simple"
rule. - The CLI error message says to use
Array<T>
instead ofT[]
Expected behavior
- Running
tslint --fix
should fix(number)[]
tonumber[]
. No error should be raised. - The CLI error message should say to use
T[]
instead of(T)[]
.
Activity
Add schema schema interface compilation script
MaximeKjaer commentedon Aug 30, 2019
I'm actually wondering what the expected behavior should be. I suggested that
(number)[]
should be fixed tonumber[]
, but I'm starting to think that no error should be raised in the first place, i.e. that(number)[]
be considered correct.There are no rules that fix the following (playground link):
Since TSLint doesn't consider this an error, and doesn't fix it, it would be inconsistent to consider the following an error:
As a side note, some formatters (notably, Prettier) remove parentheses in the first example, but not in the second, which I suppose means that they consider the latter to be stylistically acceptable.
Perhaps the solution to this issue is simply to consider a parenthesized type to be "simple" if its contents are simple. In other words, the fix would be to ignore parentheses when deciding whether something is a simple type.
I'd therefore like to revise the expected behavior:
Expected behavior
No error is raised for
(T)[]
inarray-simple
modeAdd schema schema interface compilation script
ayazhafiz commentedon Aug 30, 2019
I am inclined to favor this behavior as well. It's also interesting to note how TSLint fixes parenthesized non-simple array types.
Is the desired behavior to remove only one layer of parentheses, or all of them (or maybe even none at all)? I'm not sure, but I think may decision made should be consistent.
The parentheses in
(number&string)[]
have a semantic role, whereas the parentheses in(number)[]
are a stylistic choice. If we choose to preserve stylistic choices made with parentheses, it makes sense to strip parentheses only where they no longer play a semantic role.What I mean by this is
(number&string)[]
is fixed toArray<number&string>
(the only pair of parentheses is stripped because its semantic role is replaced by generics syntax)((number&string))[]
is fixed toArray<(number&string)>
(one pair of parentheses in the original form plays a semantic role; the other is stylistic)(number)[]
is not fixed because its parentheses are a stylistic choice.This goes a little beyond the scope of this PR, but it's one argument for accepting
(T)[]
as valid.Fix parenthesized simple array types with array-simple (palantir#4844)
MaximeKjaer commentedon Aug 30, 2019
I agree with this: I think it's safe to remove parentheses that have a semantic role, but that it is best to let a formatter decide what to do with parentheses serving a stylistic role.
So this bug is fixed by:
--fix
behavior(T)
is considered simple ifT
is simple. This means(T)[]
is acceptable with thearray-simple
option.I submitted a PR doing just that :)
Fix parenthesized simple array types with array-simple (#4844) (#4846)
82 remaining items