Update import/extensions rules in typescript config
#2875
Conversation
|
Related to #2853 Successfully tested end-to-end. |
OlivierZal
changed the title
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.
No description provided.