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

[dimafirsov]

🔎 Search Terms

noUncheckedSideEffectImports

🕗 Version & Regression Information

• This changed between versions 5.5.* and 5.6.*
• This changed in commit or PR - Add new option "noUncheckedSideEffectImports" #58941

⏯ Playground Link

https://stackblitz.com/edit/vitejs-vite-v2boec?file=src%2Fmain.ts

💻 Code

import 'does-not-exist.css';

🙁 Actual behavior

With the noUncheckedSideEffectImports ts compiler flag on, the error is not thrown for the non-existing .css file reference (side effect import) when executing tsc. Actually, it is not thrown for any file extension other than js.

🙂 Expected behavior

As stated here, the error should be thrown for non-existing css file/module reference.

Additional information about the issue

Steps to reproduce:

1. Visit the playgound typescript project
2. Expect the runtime error (because of the non-existing file reference in the code)
3. main.ts - notice the side effect import of non-existing CSS file
4. globals.d.ts - notice the file and its contents (as described HERE)
5. Open new stackblitz terminal
6. Execute the following: npm run check
7. Observe a result

Expected result: tsc throws an error for the non-existing file reference

Actual result: Specifically, the tsc successfully finishes with no errors. In general, tsc doesn't throw no matter the file extension, EXCEPT for the .js

[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

[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).