Repository navigation
Node16 module resolution doesn't check side effect imports #50394
Description
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
// @module: Node16
import "./file";🙁 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:
- I haven't been able to set this up in the bug workbench, but what happens if the file is being imported from
node_modulesand has a corresponding.d.tswith adeclare ...in it? Will thatdeclareget applied? - Wouldn't this be useful to have either way? I guess ESLint could fill this void, but seeing how
eslint-plugin-importis dragging its feet onimport/extensions, there's little hope for that.
Apologies if this has been addressed before, couldn't find.
Activity
DanielRosenwasser commentedon Aug 23, 2022
I believe that this has come up in discussion with Andrew Branch (@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.
fatcerberus commentedon Aug 23, 2022
wait, I’m confused - why is this a concern only for side-effect imports?
andrewbranch commentedon Aug 23, 2022
I also don’t understand that sentence 🤔
andrewbranch commentedon Jan 12, 2023
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
".*css"or a file atstyles.d.css.tsvia #51435. But both of these feel a bit pointless for a side-effect import, since the types written in that declaration will never be observed.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.
fatcerberus commentedon Jan 14, 2023
Perhaps the error should only be unsilenced in
bundlerresolution mode, assuming that's still planned to be a thing (I haven't been following it too closely as I'm more interested inminimal--browser ESM mode--which is on hold). That CSS import doesn't really make sense outside the context of a toolchain that's actually going to do something with it; even if the runtime understood it, I have to imagine it'd be a no-op pretty much for the same reason it is in TS.Hmm, in theory though, the types (if they exist) might still be observable if the
.d.tsincludes any global declarations, right? Isimport type 'foo';a thing?andrewbranch commentedon Jan 17, 2023
You’re right, any global declarations would be observed (and there is no
import type "foo"). That just doesn’t seem like what you want if you’re just trying to load a CSS file globally or something.qwelias commentedon Nov 30, 2023
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"
Like imagine not requiring a driver to stop at red light if they're a tourist because what if in the country they're from it's ok.
jakebailey commentedon Jun 20, 2024
For fun, I have sent #58941 which adds a
resolveSideEffectImportsoption; it seems to catch everything people have already mentioned here, but a lot of things on DefinitelyTyped which I think are actually accidentally broken.