Update import/extensions rules in typescript config
#2875
Conversation
|
Related to #2853 Successfully tested end-to-end. |
import/extensions rules in typescript config
|
|
||
| const allExtensions = [...typeScriptExtensions, '.js', '.jsx']; | ||
|
|
||
| const typeScriptRules = Object.fromEntries( | ||
| typeScriptKeys.map((key) => [key, 'never']), |
There was a problem hiding this comment.
Doesn’t this depend on your resolution settings in tsconfig?
There was a problem hiding this comment.
In the most recent versions of TypeScript we can configure in the tsconfig if we want ts extensions to be allowed or not while importing (https://www.typescriptlang.org/tsconfig#allowImportingTsExtensions).
That's why it's good to deactivate this eslint rule for ts extensions, so the tsconfig can raise an error (or not) without conflicting with the eslint rule.
There was a problem hiding this comment.
then it shouldn't be setting it to "never", should it? We don't have an "ignore" setting, so i don't think adding this makes much sense.
There was a problem hiding this comment.
You're right, but never is the default and main use of typescript (compilation), the other use is type-checking-only.
In my opinion a user setting the eslint-import-plugin typescript config wouldn't like to constantly have an eslint issue although he respects the typescript rules.
There was a problem hiding this comment.
I agree - which is why the override here should be disabling the rule, not configuring it.
There was a problem hiding this comment.
Ok, so should depend on moduleResolution
There was a problem hiding this comment.
@ljharb, and what about a new entry point typescript-node16 importing current typescript config and adding overrides to it?
There was a problem hiding this comment.
a new entry point may be reasonable, but calling it "node16" implies you should be using it if you're on node 16+, which isn't the case.
instead could we use tsconfig-paths to read the tsconfig and dynamically set the right thing?
There was a problem hiding this comment.
I'm not familiar with but I can try. I need to have in mind that sometimes a tsconfig extends another one beforehand.
There was a problem hiding this comment.
True, but we don't support that since we're stuck on tsconfig-paths v3, and they didn't backport that feature from v4. It would be automatically handled if that changes, so you don't have to worry about it.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2875 +/- ##
==========================================
- Coverage 95.13% 94.96% -0.17%
==========================================
Files 68 68
Lines 2959 2962 +3
Branches 1035 1035
==========================================
- Hits 2815 2813 -2
- Misses 144 149 +5 ☔ View full report in Codecov by Sentry. |
|
@OlivierZal are you no longer interested in completing this PR? |
|
Hi @ljharb, you're right I should have explained why. Actually I don't really remember why I needed it 😅 However I don't think it's a good thing to do anymore since TypeScript 5.7 now allows to use |
No description provided.