No error for non-existing css side effect import with `noUncheckedSideEffectImports` flag on about typescript

[uhyo]

You cannot benefit from --noUncheckedSideEffectImports while using ambient module declaration.

declare module '*.css' in your globals.d.ts is the way to have TS assume every module specifier that ends with .css is valid.

Mention to .css files in the 5.6 release announcement is all about use cases not covered by --noUncheckedSideEffectImports.

If you want to utilize --noUncheckedSideEffectImports for CSS imports, you need to stop using ambient module declarations and instead use a solution like this that generates .d.ts files next to each of your .css files

[RyanCavanaugh]

I can't reproduce what you're reporting there.

D:\Throwaway\nusi>tsc
a.ts:1:8 - error TS2307: Cannot find module 'foo.css' or its corresponding type declarations.

1 import "foo.css";
         ~~~~~~~~~

Maybe you have a @types library that also does declare module "*.css" ?

[dimafirsov]

You cannot benefit from --noUncheckedSideEffectImports while using ambient module declaration.

declare module '*.css' in your globals.d.ts is the way to have TS assume every module specifier that ends with .css is valid.

Mention to .css files in the 5.6 release announcement is all about use cases not covered by --noUncheckedSideEffectImports.

If you want to utilize --noUncheckedSideEffectImports for CSS imports, you need to stop using ambient module declarations and instead use a solution like this that generates .d.ts files next to each of your .css files

Thank you for your response and for the alternative options you gave that may make things work.

However though, it is either a confusing wording in release announcement, or it is indeed an issue.

The release announcement for this section literally reads like this:

1. Some people may have their builders configured to directly import .css files
2. this masks potential typos on side effect imports
3. That’s why TypeScript 5.6 introduces a new compiler option

A bit below we can read this:

1. When enabling this option, some working code may now receive an error, like in the CSS example above.
2. To work around this, users who want to just write side effect imports for assets might be better served by writing what’s called an ambient module declaration with a wildcard specifier

Not a word about the flag not supporting errors for .css or any other side effects import modules.

[dimafirsov]

Another thing to add to the conversation here is the name of the flag (noUncheckedSideEffectImports ) is pretty general, which makes me think it covers all the side effect imports, not just js modules.

[RyanCavanaugh]

I don't really understand what you're proposing happen here. There still needs to be a mechanism to tell TypeScript about modules which will successfully resolve but aren't on disk. That mechanism is declare module, and you used declare module. TypeScript correctly interpreted your description of the world (even if it's not what you meant to describe).

[dimafirsov]

I don't really understand what you're proposing happen here. There still needs to be a mechanism to tell TypeScript about modules which will successfully resolve but aren't on disk. That mechanism is declare module, and you used declare module. TypeScript correctly interpreted your description of the world (even if it's not what you meant to describe).

Thanks @RyanCavanaugh for joining the discussion.

Ok, it'll put it in other words. My recent testing has shown that the following side effect imports (and their variations) are well-treated by typescript and it throws an expected error (with the compiler flag on, of course):

import 'does-not-exit'
import 'does-not-exit.does-not-exit''
import 'does-not-exit.1234567'
import '1234567.1234567'
etc.

However, once there is .css in the file name (or anything css-related, like less, sass etc) ts ignores such imports, whether there is declare module '*.css' {} or not.

import 'does-not-exit.css'

I wonder why ts reacts to the .css in the name this way?

Having .css in the name of the file may not necessary mean it is a css file. Imagine a rough use case when one has a js module file that exports some stuff that generates some CSS (the reason to have css in the name). Something like *.css.js. It'll be ignored when imported incorrectly even though its a js module, unless the .js extension is specified explicitly.

[dimafirsov]

Good point @RyanCavanaugh , I think I know what's going on there. Even though the environment for the reproduction I gave was clean, it was, apparently, built by Vite. And Vite does this:

And a lot more.
I didn't know or expect that, and now everything makes total sense.

So, thank you @uhyo and @RyanCavanaugh for your input, and I'm sorry for the false alarm. Closing this one.

[dimafirsov]

Not an issue. Works as expected.