-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Node16
module resolution doesn't check side effect imports
#50394
Comments
I believe that this has come up in discussion with @andrewbranch recently. I think that Node16 users probably want to get an error under this mode, but it's hard to say - plus those users need an alternative option if they are trying to get export maps working in conjunction with a bundler. |
wait, Iβm confused - why is this a concern only for side-effect imports? |
I also donβt understand that sentence π€ |
The reason why this isnβt a no-brainer is that itβs common to do
with certain bundler configurations in order to add globally-applicable CSS to the bundle. We donβt check existence of files with arbitrary extensions, so in order to make this resolve, youβd have to add a pattern ambient module for I think I would want module resolution to be able to say βthere is a file here, but I didnβt read it because it has an unsupported extensionβ so we could count that as a successful resolution for a side-effect import. Thatβs a bigger change than just unsilencing an error. |
Perhaps the error should only be unsilenced in
Hmm, in theory though, the types (if they exist) might still be observable if the |
Youβre right, any global declarations would be observed (and there is no |
TS has nothing to do with people importing css or whatever up the toolchain, as a TS user I expect TS to be consistent in it's guarantees, including guarantees on module existence checks. "Let's ignore module existence checks if it's a side-effect import because someone may import a stylesheet" |
For fun, I have sent #58941 which adds a |
Bug Report
π Version & Regression Information
This is the behavior in every version I tried, and I reviewed the FAQ for entries about this.
β― Playground Link
Playground link with relevant code
π» Code
π Actual behavior
TypeScript says nothing.
π Expected behavior
I want TypeScript to tell me that
.js
is missing, the same way it does in any other type of import. I think I understand why it doesn't right now, because side effects have nothing to do with static analysis, so the incorrectness of the import doesn't prevent TypeScript from doing its job in any way, but:node_modules
and has a corresponding.d.ts
with adeclare ...
in it? Will thatdeclare
get applied?eslint-plugin-import
is dragging its feet onimport/extensions
, there's little hope for that.Apologies if this has been addressed before, couldn't find.
The text was updated successfully, but these errors were encountered: