@typescript-eslint/parser

This major release has been a long time coming! We've been saving up breaking changes for a while now, waiting for the ESLint v7 release which we knew would deprecate support for node version 8.

Due to our weekly release cadence, this major release mostly contains breaking changes!

Breaking Changes

Dropped support for Node version 8 (#1420)

In line with ESLint v7 - we've also dropped explicit support for node version 8.
This version of node has been end of life since 2019-12-31.
We no longer test against the version, so we provide no guarantees about whether or not future versions of our tooling will work on it.

Dropped support for TypeScript 3.2 (#2004)

Old TS versions cause us maintenance pain as we work on integrating tightly with the TypeScript APIs for performance and stability reasons.

As such we've updated our required TS version range to require a minimum of >=3.3.1.

Each version of TS brings bugfixes and features, but most importantly they bring performance improvements. TS 3.9 is releasing with a host of performance improvements that will improve both your build times, and your lint times - so you should endeavour to upgrade if you can. We cannot provide any guarantees around the performance of old TS versions.

Configs

We've updated all of our configs! We've added new rules, old rules, and removed some stylistic rules.

Check out the linked issues for more information about added/removed rules:

• breaking

  eslint-recommended config

• breaking

  recommended config

• breaking

  recommended-requiring-typechecking

Additionally, both of the recommended and recommended-requiring-typechecking sets now inherit from the eslint-recommended set. We noticed that the majority of the time, users were using the sets in tandem, so this just removes one line of config for everyone.

I.e. you can now do the following:

 extends: [
   "recommended",
-  "plugin:@typescript-eslint/eslint-recommended",
   "plugin:@typescript-eslint/recommended"
 ]

Rules Changes

• breaking

  ban-types got a rework of its default ban list to provide some more sensible defaults and remove fixers that caused users issues.

• breaking

  no-floating-promises now has the ignoreVoid option set to true by default.

• breaking

  no-non-null-asserted-optional-chain (non-breaking) now supports TS 3.9's non-null assertion changes.

• breaking

  no-unnecessary-condition

  • the ignoreRHS option has been removed. The rule will now only check the RHS when it matters (i.e. in boolean contexts).

  • the checkArrayPredicates option has been removed. The rule will now always check array predicate functions.

  • the rule now will report if you do an equality check against null/undefined when the value is not nullable.

• breaking

  prefer-nullish-coalescing

  • the fixer has been converted to a suggestion fixer always - it was unsafe in most cases.

  • removed option forceSuggestionFixer.

• breaking

  prefer-optional-chain

  • the fixer has been converted to a suggestion fixer always - it was unsafe in a number of cases.

  • removed option suggestInsteadOfAutofix.

• breaking

  restrict-template-expressions

  • now has the allowNumber option set to true by default.

  • allowNullable has been renamed to allowNullish.

• breaking

  strict-boolean-expression received a complete rework. The rule is now more configurable, with smarter defaults and more intuitive logic.

Rule Removals

The following deprecated rules have been deleted. Please switch to the listed alternative:

• breaking

  ban-ts-ignore - replaced by ban-ts-comment

• breaking

  camelcase - replaced by naming-convention

• breaking

  class-name-casing - replaced by naming-convention

• breaking

  generic-type-naming - replaced by naming-convention

• breaking

  interface-name-prefix - replaced by naming-convention

• breaking

  member-naming - replaced by naming-convention

• breaking

  no-untyped-public-signatures - replaced by explicit-module-boundary-types

AST Changes

• breaking

  typescript-estree now emits a TSEmptyBodyFunctionExpression when it encounters a function expression without a body. Previously this was done in parser (for legacy reasons). This change should only affect users directly consuming typescript-estree.

• breaking

  When a method is marked as optional (class Foo { name?() {} }) we now mark the MethodDefinition/TSAbstractMethodDefinition as optional. Previously we marked the key of the node as optional, but this only works if the key is an Identifier, and didn't work in the case of a computed key (class Foo { ['name']?() {} }).

• breaking

  Import expressions (import('foo')) now conform to the newly released ESTree spec, outputting as an ImportExpression.

• breaking

  BigInt literals now conform to the newly released ESTree spec, outputting as a Literal with a value of type bigint.

• breaking

  See also the non-breaking change below - Better handling for TS 3.9's non-null assertion changes.

Parser Services

parserServices are now always emitted from both typescript-estree and parser, regardless of the parserOptions.project configuration. (#716)

This will allow you to consume parts of the TypeScript API that are generated at the file level, like variable usage diagnostics, without requiring full type information is generated for the project.

Part of this change includes a new boolean flag on the output: parserServices.hasFullTypeInformation which is true when parserOptions.project was configured, and false otherwise.

If you were using our getParserServices function from experimental-utils, then this will be handled automatically, and you will not notice any changes. If you built your own function for resolving the parserServices, then you'll have to update accordingly.

ESLint Types (experimental-utils)

The old version of our ESLint types were based on those found in the DefinitelyTyped repo. There was a lot of missing documentation, missing properties, misnamed types.

As part of this release, we've reworked some of the internals to be much closer to the ESLint library itself. (#2023)

As part of this change, we have also added the types for the new ESLint class.
SourceCode.isSpaceBetween has also been marked as optional, because it is only available in ESLint v6+

Non-breaking changes

ESLint v7

We now have full support for ESLint v7 (#1550).

Better handling for TS 3.9's non-null assertion changes (#2036)

TS 3.9 introduced a breaking change for how non-null assertions are handled in optional chains.

Pre-3.9, x?.y!.z means (x?.y).z - i.e. it essentially scrubbed the optionality from the chain
Post-3.9, x?.y!.z means x?.y!.z - i.e. it just asserts that the property y is non-null, not the result of x?.y

We now emit a different AST when we work with TS3.9. Note that the AST is unchanged for TS3.8 and lower.

TS3.8

   x?.y!.z
// ^^^^^^^ MemberExpression
// ^^^^^   TSNonNullAssertion
// ^^^^    OptionalMemberExpression

TS3.9

   x?.y!.z
// ^^^^^^^ OptionalMemberExpression <-- NEW!
// ^^^^^   TSNonNullAssertion
// ^^^^    OptionalMemberExpression

Same for each versions

   (x?.y)!.z
// ^^^^^^^^^ MemberExpression
// ^^^^^^^   TSNonNullAssertion
// ^^^^^^    OptionalMemberExpression

   (x?.y!).z
// ^^^^^^^^^ MemberExpression
// ^^^^^^    TSNonNullAssertion
// ^^^^^     OptionalMemberExpression

The same change applies for optional call expressions.

The rule no-non-null-asserted-optional-chain was also updated to handle this appropriately. It will no longer error on x?.y!.z, but it will still error on (x?.y)!.z.