-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated typescript-eslint to v6 #54693
Updated typescript-eslint to v6 #54693
Conversation
src/compiler/checker.ts
Outdated
@@ -5732,7 +5732,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
return rightMeaning === SymbolFlags.Value ? SymbolFlags.Value : SymbolFlags.Namespace; | |||
} | |||
|
|||
function getAccessibleSymbolChain(symbol: Symbol | undefined, enclosingDeclaration: Node | undefined, meaning: SymbolFlags, useOnlyExternalAliasing: boolean, visitedSymbolTablesMap: Map<SymbolId, SymbolTable[]> = new Map()): Symbol[] | undefined { | |||
function getAccessibleSymbolChain(symbol: Symbol | undefined, enclosingDeclaration: Node | undefined, meaning: SymbolFlags, useOnlyExternalAliasing: boolean, visitedSymbolTablesMap = new Map<SymbolId, SymbolTable[]>()): Symbol[] | undefined { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@typescript-eslint/consistent-generic-constructors: "The generic type arguments should be specified as part of the constructor type arguments."
This comes from the stylistic config - it's a little more succinct to put the <...>
type parameters after the new Map
. The rule is auto-fixable.
On the contrary; we really really don't want our codebase to be the basis for good Typescript style. eslint is absolutely the right provider of those defaults. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments on the TODO-commented rules.
👍🏼 means that I like the value given in the PR; I commented on the others.
"@typescript-eslint/ban-types": "off", | ||
"@typescript-eslint/no-empty-function": "off", | ||
"@typescript-eslint/no-empty-interface": "off", | ||
"@typescript-eslint/no-unused-vars": "off", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this off because the tsconfig has the equivalent Typescript setting on? If not, what kind and how many unused variables do we have?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's this; honestly I would much prefer if we didn't use TS for this at all and instead made it a lint. So annoying to have to ensure my variables are all used just to run tests or something. At least debug skips typecheck.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only 18 failures at the moment. Not bad!
However, typescript-eslint/typescript-eslint#5017 -> gajus/eslint-plugin-jsdoc#858 is impacting the codebase here. Probably best to set up the workarounds in a separate PR IMO.
"@typescript-eslint/sort-type-constituents": "off", | ||
|
||
// Pending https://github.com/typescript-eslint/typescript-eslint/issues/4820 | ||
"@typescript-eslint/prefer-optional-chain": "off", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this off because it causes lots of churn? If so, I'd like to see it turned on, but maybe in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, and also because the rule has more false positives right now than I'm comfortable with - especially in a codebase like TypeScript's that does a lot of funky stuff with scoping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm honestly shocked we aren't getting lints from prefer-nullish-coalescing
too... I was restructuring the lint config of hereby
and hit some false positives there too on code like:
declare const a: string | undefined
declare const b: string
const foo = a || b;
Where the actual intent is that the empty string goes away. But maybe that's not a false positive.
.eslintrc.json
Outdated
"@typescript-eslint/no-empty-function": "off", | ||
"@typescript-eslint/no-empty-interface": "off", | ||
"@typescript-eslint/no-unused-vars": "off", | ||
"@typescript-eslint/sort-type-constituents": "off", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏼
@JoshuaKGoldberg I read your replies. It sounds to me like this PR is in a good state, and then needs 3 or 4 follow ups to turn on even more lint rules (and also turn off the tsconfig setting for checking unused variables). Does that sound about right to you? |
@sandersn that's correct! |
I forgot to ask: do you want to merge this with v6 beta or wait for the full release? I'll ask the rest of the team to see if anybody there cares one way or the other as well. |
Beta works for me! We've scheduled the v6 announcement blog post to go out on Monday (🤞, knock on wood, etc.). It's no trouble at all. And, bonus, anything that bumps up my TypeScript PR count makes me happy 😄 |
Looks like there's some weirdness with failing tests (jsdocThisType), so probably needs a merge from main. |
If we're going to merge this, probably it's worth merging in proximity to #54835 to reduce the speedbump of the dep change? |
Also, this PR is still pinned back to an old alpha, does that need to be bumped? Or are we just waiting for a "more real" release? |
The alphas aren't changing much release-to-release at this point. I bumped to the latest in 0fde8d4 and the only relevant change was a couple rule changes in the used configs (typescript-eslint/typescript-eslint#7157). Edit: so, actually answering: no, this doesn't need to bump to new alphas. |
Btw, I just updated to typescript-eslint@v6.0.0 stable. 🥳 |
Updated the title to reflect that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems good to me now, though given how many lints we disable, I half wonder if we should just disable the : Map
lint then send them all as follow-ups.
Here's a diff for the eslint rules that can be dropped as they are part of the eslint recommended set:
diff --git a/.eslintrc.json b/.eslintrc.json
index 56d271a3f4..69ec74d564 100644
--- a/.eslintrc.json
+++ b/.eslintrc.json
@@ -109,18 +109,18 @@
"no-null/no-null": "error",
// eslint
- "constructor-super": "error",
+ // "constructor-super": "error",
"curly": ["error", "multi-line"],
"dot-notation": "error",
"eqeqeq": "error",
"linebreak-style": ["error", "windows"],
"new-parens": "error",
"no-caller": "error",
- "no-duplicate-case": "error",
- "no-empty": "error",
+ // "no-duplicate-case": "error",
+ // "no-empty": "error",
"no-eval": "error",
"no-extra-bind": "error",
- "no-fallthrough": "error",
+ // "no-fallthrough": "error",
"no-new-func": "error",
"no-new-wrappers": "error",
"no-return-await": "error",
@@ -132,24 +132,24 @@
{ "name": "setImmediate" },
{ "name": "clearImmediate" }
],
- "no-sparse-arrays": "error",
+ // "no-sparse-arrays": "error",
"no-template-curly-in-string": "error",
"no-throw-literal": "error",
"no-trailing-spaces": "error",
"no-undef-init": "error",
- "no-unsafe-finally": "error",
- "no-unused-labels": "error",
+ // "no-unsafe-finally": "error",
+ // "no-unused-labels": "error",
"no-var": "error",
"object-shorthand": "error",
"prefer-const": "error",
"prefer-object-spread": "error",
"quote-props": ["error", "consistent-as-needed"],
"space-in-parens": "error",
- "unicode-bom": ["error", "never"],
- "use-isnan": "error",
- "no-prototype-builtins": "error",
- "no-self-assign": "error",
- "no-dupe-else-if": "error"
+ "unicode-bom": ["error", "never"]
+ // "use-isnan": "error",
+ // "no-prototype-builtins": "error",
+ // "no-self-assign": "error",
+ // "no-dupe-else-if": "error"
},
"overrides": [
// By default, the ESLint CLI only looks at .js files. But, it will also look at
I also want to (not in this PR) reorganize this eslint config to distinguish which rules are effectively formatting rules and which are not; I feel like the current ordering by plugin is not really very helpful now that we are using extends
, and I already know which rules are going to go away when we dprint.
@JoshuaKGoldberg You may have missed it, but the code box above has a scrollbar and there are 8 other ones to also remove. |
Ah, great - thanks for finishing this up! ...I did miss the scrollbar 🙈 |
Applies the following strategy for updating the linter:
rc
, but there's no meaningful difference here)recommended
andstylistic
Explanations for the changes are inline. I realize the mild hubris on my end of posting lint recommendations on the TypeScript codebase itself - seeking input as to whether we're going the wrong way on any of them. 😄
For the Todo rules, I'm interested in your opinions on whether you'd want each of them or not in the TypeScript codebase.
Fixes #54692