chore: Use typescript-eslint@v6 with reworked configs
#15716
Merged
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
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/54855/ |
|
I think the end-to-end test failures are not related to these changes? |
|
@JoshuaKGoldberg Yes, the CI error is probably unrelated. The main branch is also failing, I will take a look. |
|
It's actually a pretty good mix across the configs. You can see the list of rules enabled in the
|
JLHwung
previously approved these changes
Jun 29, 2023
JLHwung
reviewed
Jun 29, 2023
.eslintrc.cjs
Outdated
| @@ -64,12 +68,51 @@ module.exports = { | |||
| allowNamedExports: true, | |||
| }, | |||
| ], | |||
| "@typescript-eslint/no-unnecessary-type-assertion": "error", | |||
There was a problem hiding this comment.
Why was this rule turned off?
There was a problem hiding this comment.
This line would be redundant because it's now enabled in the recommended-type-checked config 😄 https://v6--typescript-eslint.netlify.app/rules/no-unnecessary-type-assertion
JLHwung
reviewed
Jun 29, 2023
.eslintrc.cjs
Outdated
| "@typescript-eslint/no-namespace": "off", | ||
| "@typescript-eslint/no-redundant-type-constituents": "off", | ||
| "@typescript-eslint/no-this-alias": "off", | ||
| "@typescript-eslint/no-unnecessary-type-assertion": "off", |
There was a problem hiding this comment.
Suggested change
| "@typescript-eslint/no-unnecessary-type-assertion": "off", |
Glad that it is now enabled by default. Well, in that case...
There was a problem hiding this comment.
Yay!
I tried this out a bit locally but ran into the following conundrum:
- Without
strictNullChecks: trueintsconfig.base.json, fixing forno-unnecessary-type-assertioncan cause issues.- Example: The
null as nullcast inpackages/babel-preset-env/src/shipped-proposals.tsavoid aObject literal's property '"transform-unicode-property-regex"' implicitly has an 'any' type.complaint
- Example: The
- With
strictNullChecks: trueintsconfig.base.json, there are quite a few complaints.- Example:
parentPathinpackages/babel-traverse/src/path/modification.ts>insertBeforeis potentiallynulland that causes type errors
- Example:
Can I propose filing a followup to enable strictNullChecks: true internally, and considering it a blocker for enabling some of these rules?
There was a problem hiding this comment.
Perhaps we can temporarily use eslint-disable-next-line with strictNullChecks: false?
I remember @JLHwung has a strictNullChecks: true branch, but it was blocked by ts bug at the time, and it may be outdated now.(I'm willing to give this a try too, if that branch is outdated)
By the way, can null as null be a special case of no-unnecessary-type-assertion?
There was a problem hiding this comment.
temporarily use
eslint-disable-next-linewithstrictNullChecks: false
That could work. In my experience that can bring positives (more lint rules, sooner) and also some negatives (folks getting confused when new edge case situations like this one pop up). What do you think?
can
null as nullbe a special case ofno-unnecessary-type-assertion?
Interesting. We haven't had a lot of users running without strictNullChecks, and haven't had to think about this case before (that I know of). Similar with undefined as undefined...
I poked a bit around it and I think it's because I'd enabled strict: true in tsconfig.eslint.json. That made typescript-eslint run with different type information than TypeScript proper. We in typescript-eslint generally don't accept bugs or feature requests for the mismatched-type-information situation because it's so rare for users to hit it.
If I turn off strictNullChecks in tsconfig.eslint.json then we end up with a bunch of no-unnecessary-type-assertion complaints for code like id as NodePath<t.Identifier | null>. Which, while technically correct, seems like a backwards step towards your goal in enabling strictNullChecks.
There was a problem hiding this comment.
Makes sense! I'm slightly leaning towards enabling this rule and ignoring edge cases, but both options are fine.
It seems this is not just happening with this PR. 🤔
https://github.com/babel/babel/pull/15681/files?diff=unified#diff-2584b855363a673ff1758cc21653fdbd86b1ad2ab7f1a851c2320999c9c6f84cR30
I had the same problem when I upgraded TS, so maybe it's not a tsconfig.eslint.json specific issue.
There was a problem hiding this comment.
Perhaps we can temporarily use
eslint-disable-next-linewithstrictNullChecks: false? I remember @JLHwung has astrictNullChecks: truebranch, but it was blocked by ts bug at the time, and it may be outdated now.(I'm willing to give this a try too, if that branch is outdated) By the way, cannull as nullbe a special case ofno-unnecessary-type-assertion?
Thanks for the reminder. I have rebased that branch but I still hits OOM: https://github.com/JLHwung/babel/tree/strict-null-checks, using TS 5.2.0 beta.
There was a problem hiding this comment.
This branch is using TS 4.8 beta. :)
There was a problem hiding this comment.
Good catch. Updated to 5.1.6 and it works for me now.
liuxingbaoyu
approved these changes
Jun 30, 2023
There was a problem hiding this comment.
#15716 (comment)
Special thanks for your detailed explanation of them, I can refer to this to enable more rules in the future!
This is a bit strange, OOM occurs on my local, can other reviewers try it? |
JoshuaKGoldberg
changed the title
|
It doesn't oom for me (on macos), but maybe we could make |
|
However, I get warnings 🤔 |
|
This may be a bug, even if I use |
|
I was testing this locally again, and I realized that for some reason it's incredibly slow. To lint a single file, on `main` it takes ~4s, mostly spent while parsing.while with this PR parsing takes 28sI also tried rebasing this PR on top of Btw @JLHwung it looks like with the new flat config we are linting polyfill dist files: and |
nicolo-ribaudo
force-pushed
the
typescript-eslint-v6
branch
from
edc781b
to
9de7dff
Compare
|
@nicolo-ribaudo Yeah previously |
Oh right, I forgot about it. I have no idea 😬 I'll just delete it. Probably I at some point had to build an old commit and it generated that folder, and we have now no build script that deletes it since it's not expected to exist anymore. |
Otherwise TS will build a watch program for every *.js file including our own test fixtures, which overwhelms the memory
JLHwung
reviewed
Jul 12, 2023
tsconfig.eslint.json
Outdated
| { | ||
| "extends": "./tsconfig.json", | ||
| "compilerOptions": { | ||
| "allowJs": true, |
There was a problem hiding this comment.
Is the allowJs option necessary? I don't see more linting errors when I disable this option. Plus Babel has migrated to TS only so it is rare that we will ever import a .js from our source file.
I would like to minimize this config and hopefully in the future we can merge tsconfig.eslint.json back to tsconfig.json so we have consistent tsconfig between type checking and linting.
|
@nicolo-ribaudo The performance issue is fixed. Previously we didn't specify the including paths in @liuxingbaoyu This change should probably also fixes the OOM issue you noticed before, please do check. |
JLHwung
added
PR: Internal 🏠
|
Amazing! Now it works great! Since I have |
liuxingbaoyu
force-pushed
the
typescript-eslint-v6
branch
from
64240f9
to
78c1e24
Compare
|
🙌 glad it's all working! I have to admit, I've lost track of what I can resolve and/or is directed at Babel folks - so I'm going to step back from updating this PR. Please do @ ping me if there's anything you want my action and/or opinion on though! I'm not unsubscribing, as I'm excited to watch things happen either way. 😄 |
|
Thanks! I go ahead and turn on the import _pluginCorejs2 from "babel-plugin-polyfill-corejs2";
// eslint-disable-next-line @typescript-eslint/no-unnecessary-type-assertion
const pluginCorejs2 = (_pluginCorejs2.default ||
_pluginCorejs2) as typeof _pluginCorejs2.default;as we are trying to support both cjs/esm build. I think this is fair and I ignore it. Side noteWhen I try to turn on the when linting this file: https://github.com/babel/babel/blob/main/packages/babel-helper-create-class-features-plugin/src/features.ts. The error is thrown at if (type.types.some(t => tsutils.isTypeFlagSet(t, ignorableFlags))) {
return;
}I assume this is a bug in the rule and cc @JoshuaKGoldberg if you are interested. |
JLHwung
approved these changes
Jul 13, 2023
nicolo-ribaudo
changed the title
typescript-eslint@v6 with reworked configs
|
Yay! Thanks for collaborating on this everyone, really happy to see this PR land! ❤️🔥 |
4 tasks
github-actions
bot
added
the
outdated
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Coming over from typescript-eslint/typescript-eslint#6760 & typescript-eslint/typescript-eslint#6760 (comment): this updates
@typescript-eslint/*to the latest v6 alpha. You can read typescript-eslint.io/blog/announcing-typescript-eslint-v6-beta#user-facing-breaking-changes for the rationale behind the config changes. Essentially, the new recommended starter configs are:"plugin:@typescript-eslint/recommended-type-checked""plugin:@typescript-eslint/stylistic-type-checked"I'm unfamiliar with the Babel codebase & its preferences so I disabled any rule that had more than one clear obvious resolution. But for each of the Todo: rules, I'd recommend reading the linked docs & deciding whether you'd want to enable it -- either in this PR (if the changes are straightforward) or in a followup.