Monorepo for all the tooling which enables ESLint to support TypeScript
OTHER License
Bot releases are hidden (Show)
Published by JamesHenry almost 4 years ago
Published by JamesHenry almost 4 years ago
parserOptions.projectFolderIgnoreList
and deduplicate resolved projects (#2819) (bf904ec), closes #2418 #2814
requireDouble
, allowDouble
, allowSingleOrDouble
options for underscores (#2812) (dd0576a)requiresQuotes
modifier (#2813) (6fc8409), closes #2761 #1483
unused
(#2810) (6a06944)exported
, global
, and destructured
(#2808) (fb254a1), closes #2239 #2512 #2318 #2802
destructured
modifier for parameter
selector (#2829) (525d2ff), closes #2828
property
and method
selectors into more granular classXXX
, objectLiteralXXX
, typeXXX
(#2807) (665b6d4), closes #1477 #2802
this: void
parameter (#2796) (878dd4a)Published by JamesHenry almost 4 years ago
Published by JamesHenry about 4 years ago
Published by JamesHenry about 4 years ago
any
/unknown
(#2671) (d690c8d)allowProtectedClassPropertyAccess
option (#2622) (bbc9e35)ignoreInferredTypes
option (#2668) (91010e8)Published by JamesHenry about 4 years ago
Published by JamesHenry about 4 years ago
Published by JamesHenry about 4 years ago
Published by JamesHenry about 4 years ago
Function
type (#2435) (e1401dc)this
return (#2437) (7c6fcee)in-try-catch
if the return is in a catch
without a finally
(#2356) (efdd521)Published by JamesHenry about 4 years ago
export =
(#2505) (3d07a99)const
as a global type variable (#2499) (eb3f6e3)Published by JamesHenry about 4 years ago
This release comes just a few months after the v3 release due to the much faster than expected turnaround on optional chaining by ESTree. Read on for more details!
ts-expect-error
to allow-with-description
(#2351) (ef85b7b92cf7b83e708bc85b58baca295955d5c8)strictNullChecks
turned on (#2345) (ee5b194e6cb813e8aed0f2889b51d12a2b6964e4)consistent-type-imports
rule (#2367) (ba9295b774765c293c94c5e82c26804ded25180d)downlevel-dts
to all packages with type declarations (a25718358e2c198e387a79d7f175baaa951ad547)@typescript-eslint/no-redeclare
(#2039) (abb0617e7cda636064193c65c73f8f8c08d8cb56)@typescript-eslint/no-shadow
(#2039) (abb0617e7cda636064193c65c73f8f8c08d8cb56)When TS 3.7 released with optional chaining in November 2019, the feature was still a Stage-3 TC39 spec. This meant that ESTree[1] did not yet have an official AST representation defined, as they only officially support Stage-4 specs.
This meant that we either had to block on TS 3.7 support, unofficially support optional chaining, or find an interim representation to use. As we had no clear timeframe around which both optional chaining would move to Stage-4, and when the ESTree AST for it would be defined, we decided the first two options were sub-optimal, and instead chose to the existing babel-eslint
AST representation. This representation has been in the ecosystem for a while and was supported by a variety of plugins.
Recently, ESTree agreed upon and merged an AST for optional chaining, which is vastly different to babel-eslint
's representation. ESLint and their parser espree
have already implemented and released support for this new AST as of ESLint v7.5.0
.
In order to correct course to match the future of the ecosystem, we've update our AST to match the new, official representation.
This means a few things right now:
Going forward, we're trying to be a bit more conservative with our choice of AST representation to help prevent this migration pain, at the cost of not being able to write lint rules for new features.
[1] ESTree is the AST representation used in the ESLint ecosystem (amongst other things). It's collectively governed by a number of projects. https://github.com/estree/estree/
decorators
from nodes that TS doesn't support decorators on (#2375)Previously, our parser would parse decorators and include them in the AST for FunctionDeclaration
s, EnumDeclaration
s and InterfaceDeclaration
s. This was originally done because the TypeScript parser treats these as syntactically valid for various reasons (the TS parser is incredibly permissive in what it allows!).
However, it's semantically invalid to have decorators for these nodes, and TypeScript will throw a semantic compile-time error. Whilst you can ignore this error with an ignore comment, TypeScript will ignore the decorator completely in the compiled output.
Additionally, babel's TypeScript parser will throw a parser error in these cases.
With this version, the parser will no longer include the decorators
property for the mentioned nodes.
Note that the parser will not error - it will just silently ignore the invalid decorators.
AST_NODE_TYPES.Import
removed (#2375)This was a cleanup item that was missed in the 3.0.0 release (#1950).
The underlying type was removed back then, so it's unlikely that anyone was still using this member.
You can read the full backstory behind this change in #1856.
In a nutshell, Scope Analysis is what enables ESLint to find and track variables as it traverses the AST. This information is consumed by rules like no-unused-vars
, no-undef
, no-shadow
, no-redeclare
, and no-use-before-define
.
With this release, we've forked ESLint's eslint-scope
package, and rebuilt it from the ground up to support TypeScript's functionality and dual-scope system.
This should mean that rules that rely upon scope analysis should all work properly, with no more false positives!
This has been marked as a breaking change for the following reasons:
@typescript-eslint/no-redeclare
@typescript-eslint/no-shadow
eslint-disable
comments that are now unnecessary, and may block your CI if you use ESLint's --report-unused-disable-directives
CLI option,parserOptions.lib
option to ensure the global types are correctly defined for rules like no-undef
.parserOptions.project
glob resolution performance (#2418)For configuration simplicity, we allow you to specify globs to parserOptions.project
.
Some users provide globs like ./**/tsconfig.json
. This sort of glob will match node_modules
and any tsconfig
s located in there (many packages do not maintain proper exclusion lists when publishing, so they publish unnecessary files like that). This is a problem for two reasons:
tsconfig
s.node_modules
.The first issue we fixed a while ago with the parserOptions.projectFolderIgnoreList
option, which defaulted to ignore node_modules
. At the time due to some weirdness with the glob
package, we implemented a manual filter after the globs were resolved.
We never really thought about the second issue. However in some cases (when there are a large number of dependencies in node_modules
... so in most cases!) this can cause a significant performance impact.
On a medium-large node_modules folder, it can take ~3-1000ms to scan the directory. For correctness and safety reasons we have to do this scan every time ESLint asks us to parse a file, which obviously adds up over a lint run.
To fix this, we've changed the underlying package we use for glob resolution. This should change the total time we spend parsing globs during a lint run from O(n)
(where n
is the number of files in the workspace) to more or less O(1)
. For more information you can see the PR.
The breaking change that comes with this is as follows:
Previously parserOptions.projectFolderIgnoreList
accepted an array of RegExp
objects or regex strings.
Now it only accepts an array of strings, which must be glob strings. You'll have to translate your regexes to globs for them to continue working.
ban-ts-comment
- change default for ts-expect-error
to allow-with-description
(#2351)ts-expect-error
was added in TS 3.9. It's like ts-ignore
, but it's slightly less dangerous because if it suppresses no errors, then the comment itself becomes a compiler error.
Whilst completely banning the comment is "best practice", in real world use cases, you might have some valid cases that requires the comment.
Previously this would require code like the following:
// some comment describing why it's disabled
// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// ts-expect-error
const x = 1 as string;
The problem is that there's no way to enforce that there is a description detailing why the suppression comment is required.
With the new default the following is considered valid code:
// ts-expect-error: some comment describing why it's disabled
const x = 1 as string;
This change makes the rule a little more flexible for real-world scenarios by banning most cases, and enforcing best practice of documenting suppressions when they're required.
typedef
- remove all rule defaults (#2352)For a long time we have discouraged using the typedef
rule. The rule exists for essentially one purpose: gradually migrating a weakly typed codebase to be stricter with the goal of enabling the noImplicitAny
and strictPropertyInitialization
compiler options.
Outside of that use-case, this rule can be harmful to your codebase: explicitly annotating every single thing is known to cause performance issues with TypeScript, and maintaining all of those annotations can be a large maintenance burden.
This rule also often causes conflicts with other rules like no-inferrable-types
, which causes headaches for some setups.
We have removed all defaults from the rule to force users to explicitly "opt-in" to all functionality.
no-unnecessary-condition
and strict-boolean-expressions
- report an error if strictNullChecks
is not turned on (#2345)Both of these rules are driven off of inspecting nullability. Because of this, both rules will not work correctly if your project does not use the strictNullChecks
compiler option.
Without strictNullChecks
, TypeScript essentially erases undefined
and null
from the types. This means when this rule inspects the types from a variable, it will not be able to tell that the variable might be null
or undefined
, which essentially makes this rule a lot less useful.
If for some reason you cannot turn on strictNullChecks
, but still want to use one of these rules - you can use the new allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing
option to allow it.
Note that the behavior of this rule is undefined with the compiler option turned off. We will not accept bug reports if you are using this option.
consistent-type-imports
(#2367)TypeScript 3.8 introduced type-only imports. This is an important feature for transpilers (like babel), as it allows them to very easily determine when an import/export can be excluded from the output code.
With the new scope analyser we've introduced in this version, we've enable a number of powerful abilities that were previously difficult or impossible for us to do.
This rule is an example of a use-case that was previously nearly impossible to do that is now relatively simple. This rule can help you ensure that any imports that are only used in type locations are properly declared as a type-only import.
It also includes a powerful fixer to help automatically separate your imports for you.
downlevel-dts
to all packages with type declarations (a25718358e2c198e387a79d7f175baaa951ad547)This is a minor change to ensure that our type declarations remain backwards compatible with older versions as we start to leverage new TS features.
We were already using downlevel-dts
in a few packages, this just increases the coverage to 100%.
Published by JamesHenry about 4 years ago