Node16 module resolution doesn't check side effect imports

[alecmev]

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:

1. I haven't been able to set this up in the bug workbench, but what happens if the file is being imported from node_modules and has a corresponding .d.ts with a declare ... in it? Will that declare get applied?
2. Wouldn't this be useful to have either way? I guess ESLint could fill this void, but seeing how eslint-plugin-import is dragging its feet on import/extensions, there's little hope for that.

Apologies if this has been addressed before, couldn't find.

[DanielRosenwasser]

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.

[fatcerberus]

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?

[andrewbranch]

I also don’t understand that sentence 🤔

[andrewbranch]

The reason why this isn’t a no-brainer is that it’s common to do

import "./styles.css"

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 at styles.d.css.ts via #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]

Perhaps the error should only be unsilenced in bundler resolution mode, assuming that's still planned to be a thing (I haven't been following it too closely as I'm more interested in minimal--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.

But both of these feel a bit pointless for a side-effect import, since the types written in that declaration will never be observed.

Hmm, in theory though, the types (if they exist) might still be observable if the .d.ts includes any global declarations, right? Is import type 'foo'; a thing?

[andrewbranch]

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]

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]

For fun, I have sent #58941 which adds a resolveSideEffectImports option; it seems to catch everything people have already mentioned here, but a lot of things on DefinitelyTyped which I think are actually accidentally broken.