Update @typescript-eslint/parser to the latest version 馃殌 #134
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![greenkeeper[bot]](https://avatars.githubusercontent.com/in/505?s=60&v=4){kind=small}
Pull Request Test Coverage Report for Build 1042
馃挍 - Coveralls |
|
馃毃 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! 馃挏 馃殮馃挩 馃挌 Find out how to migrate to Snyk at greenkeeper.io
Update to this version instead 馃殌 Release Notes for v3.0.13.0.1 (2020-05-25)Bug Fixes
CommitsThe new version differs by 17 commits.
There are 17 commits in total. See the full diff |
|
馃毃 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! 馃挏 馃殮馃挩 馃挌 Find out how to migrate to Snyk at greenkeeper.io
|
|
馃毃 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! 馃挏 馃殮馃挩 馃挌 Find out how to migrate to Snyk at greenkeeper.io
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
馃毃 Reminder! Less than one month left to migrate your repositories over to Snyk before Greenkeeper says goodbye on June 3rd! 馃挏 馃殮馃挩 馃挌
Find out how to migrate to Snyk at greenkeeper.io
The devDependency @typescript-eslint/parser was updated from
2.34.0to3.0.0.This version is not covered by your current version range.
If you don鈥檛 accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.
Publisher: jameshenry
License: BSD-2-Clause
Release Notes for v3.0.0
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.
Both of the
recommendedandrecommended-requiring-typecheckingsets now inherit from theeslint-recommendedset. 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.Check out the linked issues for more information about added/removed rules:
eslint-recommendedconfig (#1273)recommendedconfig (#1423)recommended-requiring-typechecking(#1423)Rules Changes
ban-typesgot a rework of its default ban list to provide some more sensible defaults and remove fixers that caused users issues. (#848)no-floating-promisesnow has theignoreVoidoption set to true by default. (#2003)no-unnecessary-conditionignoreRHSoption has been removed. The rule will now only check the RHS when it matters (i.e. in boolean contexts). (#1163)checkArrayPredicatesoption has been removed. The rule will now always check array predicate functions. (#1579)null/undefinedwhen the value is not nullable. (#1659)prefer-nullish-coalescingforceSuggestionFixer.prefer-optional-chainsuggestInsteadOfAutofix.restrict-template-expressionsallowNumberoption set to true by default. (#2005)allowNullablehas been renamed toallowNullish. (#2006)strict-boolean-expressionreceived a complete rework. The rule is now more configurable, with smarter defaults and more intuitive logic. (#1515)Rule Removals
The following deprecated rules have been deleted. Please switch to the listed alternative:
ban-ts-ignore- replaced byban-ts-commentcamelcase- replaced bynaming-conventionclass-name-casing- replaced bynaming-conventiongeneric-type-naming- replaced bynaming-conventioninterface-name-prefix- replaced bynaming-conventionmember-naming- replaced bynaming-conventionno-untyped-public-signatures- replaced byexplicit-module-boundary-typesAST Changes
typescript-estreenow emits aTSEmptyBodyFunctionExpressionwhen it encounters a function expression without a body. Previously this was done inparser(for legacy reasons). This change should only affect users directly consumingtypescript-estree. (#1289)class Foo { name?() {} }) we now mark theMethodDefinition/TSAbstractMethodDefinitionas optional. Previously we marked thekeyof the node asoptional, but this only works if thekeyis anIdentifier, and didn't work in the case of a computedkey(class Foo { ['name']?() {} }). (#1429)import('foo')) now conform to the newly released ESTree spec, outputting as anImportExpression. (#1950)Literalwith a value of typebigint. (#1999)Parser Services
parserServicesare now always emitted from bothtypescript-estreeandparser, regardless of theparserOptions.projectconfiguration. (#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.hasFullTypeInformationwhich istruewhenparserOptions.projectwas configured, andfalseotherwise.If you were using our
getParserServicesfunction fromexperimental-utils, then this will be handled automatically, and you will not notice any changes. If you built your own function for resolving theparserServices, 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
ESLintclass.SourceCode.isSpaceBetweenhas 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!.zmeans(x?.y).z- i.e. it essentially scrubbed the optionality from the chainPost-3.9,
x?.y!.zmeansx?.y!.z- i.e. it just asserts that the propertyyis non-null, not the result ofx?.yPreviously
x?.y!.zproducedMemberExpression > TSNonNullAssertion > OptionalMemberExpression.Now it produces
OptionalMemberExpression > TSNonNullAssertion > OptionalMemberExpression.Note that both
(x?.y)!.zand(x?.y!).zstill produceMemberExpression > TSNonNullAssertion > OptionalMemberExpression.The same applies for call expressions.
The rule
no-non-null-asserted-optional-chainwas also updated to handle this appropriately. It will no longer error onx?.y!.z, but it will still error on(x?.y)!.z.Bug Fixes
Commits
The new version differs by 34 commits.
1765a17chore: remove v3 canary Ci step7e39f5bv3.0.03dfc46dfeat: add index files to parser and typescript-estree52b6085feat(eslint-plugin): [prefer-nullish-coalescing][prefer-optional-chain] remove unsafe fixersae82ea4fix(experimental-utils): add back SourceCode.isSpaceBetweenTokensfe59f69fix(eslint-plugin): correct parser peerDep versionf199cbdfix(typescript-estree): remove now defunctImportnode typea35026dchore: provide more granularity in the CI logs (#2024)06869c9feat(experimental-utils): upgrade eslint types for v7 (#2023)208de71feat: upgrade to ESLint v7 (#2022)7ad4d7cfeat: bump minimum required TS version (#2004)264b017feat(eslint-plugin): [restrict-template-expressions] renameallowNullabletoallowNullish(#2006)bfd9b60feat(eslint-plugin): [no-unnecessary-condition] removecheckArrayPredicatesand always check it (#1579)7fa9060feat(eslint-plugin): [no-unnecessary-condition] report when non-nullish is compared tonull/undefined(#1659)643ec24feat(eslint-plugin): [restrict-template-expressions]allowNumber: trueby default (#2005)There are 34 commits in total.
See the full diff
FAQ and help
There is a collection of frequently asked questions. If those don鈥檛 help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper bot 馃尨