Skip to content
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

[import/extensions] Option to enforce extensions for type-only imports #2530

Open
trevor-scheer opened this issue Aug 23, 2022 · 5 comments
Open

Comments

@trevor-scheer
Copy link

trevor-scheer commented Aug 23, 2022

We have a use case for enforcing the .js extension even on type-only imports (I'm aware this is odd).

This requirement stems from supporting TS users using modules (by specifying "type": "module" in their package.json) and specifying nodenext for moduleResolution options in their tsconfig.

Some context can be gleaned from this PR, where I created a failing test using ^this configuration and proceeded to resolve the errors by adding .js extensions to type-only imports.
apollographql/apollo-server#6731

Related: #2270

Does another option seem reasonable to enforce extensions on type-only imports as well? I'd be happy to open a PR to introduce this if so.

@ljharb
Copy link
Member

ljharb commented Aug 23, 2022

Duplicate of #2111, i think.

It seems overwhelmingly horrific to add a .js extension when it's not even JS that's being imported, so I don't think it's reasonable to do that. Perhaps the TS import resolver could handle it, but that shouldn't be part of the main plugin. cc @JounQin

@JounQin
Copy link
Collaborator

JounQin commented Aug 23, 2022

Handle what? The ts resolves .js as .ts correctly, What can I do in the resolver?

See also #2111 (comment)

@trevor-scheer
Copy link
Author

While I don't disagree (re: overwhelmingly horrific), it looks like this is the world TS users are in for, as some others in #2111 have pointed out. I've gotten some context reading through #2111, but some things are still fuzzy.

IIUC, the PR I referenced, while related, is right to ignore type imports because import/extensions is not interested in (but is generally compatible with) typescript specifics. That's probably grounds for closing this issue, possible duplicate aside.

This comment #2111 (comment) seemed to be interesting to folks, though I'm not sure there's agreement there and conversation seems to have gone in a slightly different direction. Is there some consensus around the end of the conversation there but just waiting for someone motivated to take action?

@JounQin is the reference to the comment directed to me or @ljharb? I don't think it's particularly interesting to me, but there's a lot I don't know yet about eslint plugins.

@ljharb best next step? I'd guess offering my assistance on #2111, mostly asking in case I've misunderstood anything.

@mxdvl
Copy link

mxdvl commented Aug 7, 2023

As moduleResolution:"bundler" and allowImportingTsExtensions are available since TS 5.0, it would be even more important to support enforcing extensions from type imports.

@bodinsamuel
Copy link

Hey team, do we have an update on this or an alternatives solution? ☺️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants