[BUG] `.css` ESM imports should resolve to `.css.{js,jsx,ts,tsx}` if a css file doesn't exist on disk

[mxmul]

Bug Report Quick Checklist

• [x] I am on the latest version of Snowpack & all plugins.
• [x] I use package manager yarn
• [x] I run Snowpack on OS Mac
• [x] I run Snowpack on Node.js v12+

Describe the bug

If you have a JS/TS file named like styles.css.ts, snowpack isn't able to resolve it when the import specifier looks like import './styles.css'.

It appears that snowpack's module resolution algorithm short-circuits, and it assumes this import must refer to a styles.css file on disk. There is no such file, so the dev server 404s.

To Reproduce

1. npm init snowpack-app --template @snowpack/app-template-blank

2. apply this diff:

   diff --git a/src/index.js b/src/index.js
   index a2e26fd..c7f1b4a 100644
   --- a/src/index.js
   +++ b/src/index.js
   @@ -4,6 +4,7 @@
   **/
   
   import confetti from 'canvas-confetti';
   +import './styles.css';
   
   confetti.create(document.getElementById('canvas'), {
   resize: true,
   diff --git a/src/styles.css.js b/src/styles.css.js
   new file mode 100644
   index 0000000..6be0237
   --- /dev/null
   +++ b/src/styles.css.js
   @@ -0,0 +1 @@
   +console.log('hello world');

3. Load the dev server
4. See a 404 for styles.css.proxy.js

Expected behavior

Snowpack should resolve these imports to the .css file on disk if one exists. If there is no such file, it should assume this is a JS/TS import with an implicit file extension and try to resolve to a.css.js or .css.ts file on disk.

Anything else?

This came up as an issue when trying to write a snowpack plugin for vanilla-extract; that library uses .css.ts files and it's documentation suggests importing those files from TS like import { className } from './styles.css'.

Importing the files with an explicit .css.js extension is a viable workaround, but this behavior feels like a bug in Snowpack.

[drwpow]

Thanks for raising. Agree that this isn’t expected, but as a workaround I’d recommend specifying the full extension always. We actually think omitting extensions is an anti-practice, but we do try and resolve them for you just to adapt to how people are familiar with writing code. ESM requires full extensions in the browser, so it’s always good to get in the habit.

There may not be a fix for this anytime soon, as that would involve checking the disk constantly for every file during resolution. To keep Snowpack speedy, we try to keep disk reads/writes to a minimum, and introducing a disk read here would result in noticable slowness in Snowpack (speaking from experience—I recently tried an experiment with this).

[mxmul]

@drwpow I have a PR ready that should fix this, and doesn't add any additional file operations: https://github.com/snowpackjs/snowpack/pull/3315

[drwpow]

@drwpow I have a PR ready that should fix this, and doesn't add any additional file operations: #3315

Ah I missed that linked PR! Sorry; taking a look now! 👀