Monorepo for all the tooling which enables ESLint to support TypeScript
OTHER License
Bot releases are hidden (Show)
Published by JamesHenry about 4 years ago
Published by JamesHenry about 4 years ago
Published by bradzacher over 4 years ago
See the full release - https://github.com/typescript-eslint/typescript-eslint/releases/tag/v4.0.0
Published by JamesHenry over 4 years ago
call
(#2313) (30fafb0)Published by JamesHenry over 4 years ago
const
variables (#2291) (156d058)decoratedFunctions
option (#2295) (88f08f4)Published by JamesHenry over 4 years ago
Published by JamesHenry over 4 years ago
Published by JamesHenry over 4 years ago
Published by JamesHenry over 4 years ago
ignoreStringArrays
option (#1972) (6dee784)ban-tslint-comment
(#2140) (43ee226)no-confusing-non-null-assertion
(#1941) (9b51c44)Published by JamesHenry over 4 years ago
Published by JamesHenry over 4 years ago
Intl
(#2090) (f2fa82c)CLIEngine
& ESLint
(#2083) (014341b)BigInt
with _
numeric separator (#2067) (66f1627)Published by bradzacher over 4 years ago
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!
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.
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.
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:
eslint-recommended
config (#1273)recommended
config (#1423)recommended-requiring-typechecking
(#1423)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"
]
ban-types
got a rework of its default ban list to provide some more sensible defaults and remove fixers that caused users issues. (#848)no-floating-promises
now has the ignoreVoid
option set to true by default. (#2003)no-non-null-asserted-optional-chain
(non-breaking) now supports TS 3.9's non-null assertion changes.no-unnecessary-condition
ignoreRHS
option has been removed. The rule will now only check the RHS when it matters (i.e. in boolean contexts). (#1163)checkArrayPredicates
option has been removed. The rule will now always check array predicate functions. (#1579)null
/undefined
when the value is not nullable. (#1659)prefer-nullish-coalescing
(52b60852d0ba6bb6abe519c9d3ec1b231793e91d)
forceSuggestionFixer
.prefer-optional-chain
(52b60852d0ba6bb6abe519c9d3ec1b231793e91d)
suggestInsteadOfAutofix
.restrict-template-expressions
allowNumber
option set to true by default. (#2005)allowNullable
has been renamed to allowNullish
. (#2006)strict-boolean-expression
received a complete rework. The rule is now more configurable, with smarter defaults and more intuitive logic. (#1515)The following deprecated rules have been deleted. Please switch to the listed alternative:
ban-ts-ignore
- replaced by ban-ts-comment
camelcase
- replaced by naming-convention
class-name-casing
- replaced by naming-convention
generic-type-naming
- replaced by naming-convention
interface-name-prefix
- replaced by naming-convention
member-naming
- replaced by naming-convention
no-untyped-public-signatures
- replaced by explicit-module-boundary-types
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
. (#1289)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']?() {} }
). (#1429)import('foo')
) now conform to the newly released ESTree spec, outputting as an ImportExpression
. (#1950)Literal
with a value of type bigint
. (#1999)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.
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+
We now have full support for ESLint v7 (#1550).
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
.
Published by JamesHenry over 4 years ago
Published by JamesHenry over 4 years ago