v4.6.0

4.6.0 (2020-10-26)

Bug Fixes

• eslint-plugin: [method-signature-style] correct fixer for overloads in an object literal type (#2708) (0763913)
• eslint-plugin: [method-signature-style] don't auto-fix interfaces within namespaces (#2678) (e012049)
• eslint-plugin: [prefer-string-starts-ends-with] Check negative indices in the second position for slice (#2696) (66e9c6e)

Features

• eslint-plugin: [ban-types] support banning [] (#2704) (ef8b5a7), closes #2582
• eslint-plugin: add no-unnecessary-type-constraint rule (#2516) (880ac75)
• eslint-plugin: add extension rule space-infix-ops (#2593) (343d20d)

v4.5.0

4.5.0 (2020-10-19)

Bug Fixes

• eslint-plugin: [array-type] fix issues with readonly option (#2667) (63d1d81)
• eslint-plugin: [lines-between-class-members] fix typo in schema (#2681) (a2a2514)
• eslint-plugin: [naming-convention] check bodyless function parameters (#2675) (c505863)
• eslint-plugin: [no-invalid-this] allow "this" in class property definitions (#2685) (dccb6ee)
• eslint-plugin: [no-misused-promises] False negative in LogicalExpression (#2682) (30a6951), closes #2544
• eslint-plugin: [no-unnecessary-type-assertion] correct fixer for vue files (#2680) (55111af)
• eslint-plugin: [return-await] do not auto-fix when type is any/unknown (#2671) (d690c8d)
• parser: minor fix regexp, map-filter to reduce (#2684) (f1329f6)

Features

• eslint-plugin: [dot-notation] add allowProtectedClassPropertyAccess option (#2622) (bbc9e35)
• eslint-plugin: [prefer-readonly-parameter-types] add ignoreInferredTypes option (#2668) (91010e8)
• eslint-plugin: [restrict-plus-operands] add intersection type determination logic (#2628) (da71362)
• typescript-estree: add flag EXPERIMENTAL_useSourceOfProjectReferenceRedirect (#2669) (90a5878)

v4.4.1

4.4.1 (2020-10-12)

Bug Fixes

• eslint-plugin: [ban-ts-comment] support block comments (#2644) (9c3c686)
• eslint-plugin: [ban-types] allow banning types with specific parameters (#2662) (77732a2)
• eslint-plugin: [consistent-type-assertions] check type assertion in jsx props (#2653) (393e925)
• eslint-plugin: [no-duplicate-imports] distinguish member, default (#2637) (c71f423)
• eslint-plugin: [no-throw-literal] false positive with logical expressions (#2645) (57aa6c7)
• eslint-plugin: [no-unused-vars] fix false positives for duplicated names in namespaces (#2659) (0d696c7)
• eslint-plugin: [no-use-before-define] correctly handle typeof type references (#2623) (8e44c78)
• scope-manager: don't create a variable for global augmentation (#2639) (6bc9325)

v4.4.0

4.4.0 (2020-10-05)

Features

• eslint-plugin: add consistent-indexed-object-style rule (#2401) (d7dc108)
• eslint-plugin: add extension rule no-duplicate-imports (#2609) (498f397)

v4.3.0

4.3.0 (2020-09-28)

Bug Fixes

• eslint-plugin: added safe getTypeOfPropertyOfType wrapper (#2567) (7cba2de)
• experimental-utils: treat RuleTester arrays as readonly (#2601) (8025777)

Features

• eslint-plugin: [no-invalid-void-type] add option to allow this: void (#2481) (ddf5660)

v4.2.0

4.2.0 (2020-09-21)

Bug Fixes

• eslint-plugin: [naming-convention] ignore properties inside object patterns (#2566) (53a3cbc)
• eslint-plugin: [prefer-ts-expect-error] support block comments (#2541) (c6f72fb)
• scope-manager: correct analysis of inferred types in conditional types (#2537) (4f660fd)

Features

• eslint-plugin: add extension rule comma-dangle (#2416) (f7babcf)

v4.1.1

4.1.1 (2020-09-14)

Bug Fixes

• eslint-plugin: [naming-convention] allow an array of selectors with types and modifiers (#2415) (7ca54c3)
• eslint-plugin: [no-implied-eval] handle the Function type (#2435) (e1401dc)
• eslint-plugin: [no-unused-vars] better handling for declared modules (#2553) (02d72d4), closes #2523
• eslint-plugin: [no-use-before-define] false positive for function type arguments (#2554) (189162d), closes #2527
• eslint-plugin: [prefer-function-type] handle this return (#2437) (7c6fcee)
• eslint-plugin: [return-await] don't error for in-try-catch if the return is in a catch without a finally (#2356) (efdd521)

v4.1.0

4.1.0 (2020-09-07)

Bug Fixes

• eslint-plugin: [explicit-module-boundary-types] cyclical reference infinite recursion crash (#2482) (8693653)
• eslint-plugin: [no-unused-vars] correct detection of unused vars in a declared module with export = (#2505) (3d07a99)
• eslint-plugin: [no-unused-vars] properly handle ambient declaration exports (#2496) (4d3ce5f)
• eslint-plugin: [no-use-before-define] false positive with jsx pragma reference (#2503) (5afeeab), closes #2502
• eslint-plugin: [typedef] false positive for rest parameter with array destructuring (#2441) (2ada5af)
• eslint-plugin: handle missing message IDs in eslint v5/v6 (#2461) (ffdfade)
• scope-manager: add const as a global type variable (#2499) (eb3f6e3)
• scope-manager: correctly handle inferred types in nested type scopes (#2497) (95f6bf4)
• scope-manager: don't create references for intrinsic JSX elements (#2504) (cdb9807)
• scope-manager: fallback to lib 'esnext' or 'es5' when ecma version is unsupported (#2474) (20a7dcc)
• scope-manager: support rest function type parameters (#2491) (9d8b4c4), closes #2449
• scope-manager: support tagged template string generic type parameters (#2492) (a2686c0)
• scope-manager: support type predicates (#2493) (a40f54c), closes #2462
• scope-manager: treat type imports as both values and types (#2494) (916e95a), closes #2453

Features

• eslint-plugin: [no-shadow] add option ignoreFunctionTypeParameterNameValueShadow (#2470) (bfe255f)
• eslint-plugin: add extension rule no-loop-func (#2490) (36305df)
• scope-manager: add support for JSX scope analysis (#2498) (f887ab5), closes #2455 #2477

v4.0.1

4.0.1 (2020-08-31)

Bug Fixes

• eslint-plugin: update parser dependency range (#2445) (2cb6620), closes #2444

v4.0.0

4.0.0 (2020-08-31)

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!

Summary of Changes

Breaking:

• feat: support new ESTree optional chaining representation (#2308) (a4bd2a8)
• feat: consume new scope analysis package (#2039) (abb0617)
• feat(eslint-plugin): [ban-ts-comment] change default for ts-expect-error to allow-with-description (#2351) (ef85b7b)
• feat(eslint-plugin): [typedef] remove all default options (#2352) (13bd4dd)
• fix: correct decorator traversal for AssignmentPattern (#2375) (5ab473c)
• feat(eslint-plugin): [no-unnecessary-condition][strict-boolean-expressions] add option to make the rules error on files without strictNullChecks turned on (#2345) (ee5b194)
• feat(typescript-estree): switch to globby (#2418) (789c439)

Non-Breaking:

• feat(eslint-plugin): add consistent-type-imports rule (#2367) (ba9295b)
• feat: add downlevel-dts to all packages with type declarations (a257183)
• feat(eslint-plugin): add extension rule @typescript-eslint/no-redeclare (#2039) (abb0617)
• feat(eslint-plugin): add extension rule @typescript-eslint/no-shadow (#2039) (abb0617)

---

Breaking Changes

AST Changes

Support official ESTree optional chaining syntax (#2204)

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:

1. The ESLint core rules will have complete support for optional chaining, without need for extension rules 🎉
   • you will need to upgrade to at least ESLint 7.5.0 in order to have support in lint rules
2. Users might have to wait for plugins outside this project to update their logic to support this new AST.

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/

Remove decorators from nodes that TS doesn't support decorators on (#2375)

Previously, our parser would parse decorators and include them in the AST for FunctionDeclarations, EnumDeclarations and InterfaceDeclarations. 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.

TypeScript Scope Analysis (#2039)

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:

• there may be some config changes required for existing rules,
• there are some new extension rules that have been added to better support TS that users will need to switch to:
  • @typescript-eslint/no-redeclare
  • @typescript-eslint/no-shadow
• there will be eslint-disable comments that are now unnecessary, and may block your CI if you use ESLint's --report-unused-disable-directives CLI option,
• there will likely be a number of new lint errors as affected rules will now functioning correctly,
• some users may need to configure the new parserOptions.lib option to ensure the global types are correctly defined for rules like no-undef.
• some rules outside this project may have been implicitly relying upon the scope analyser not understanding TS types - meaning they may need some adjustments.

Improve 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 tsconfigs 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:

1. it will cause us to find and parse additional, useless tsconfigs.
2. it will cause the glob handler to waste time traversing 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.

Rule Changes

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 `strictPropertyInitializa...