[BUG] Requested content ".css" but built .scss.

[cain-wang]

Bug Report Quick Checklist

• I am on the latest version of Snowpack & all plugins.
• I use package manager ____ (Fill in: npm, yarn, pnpm, etc).
• I run Snowpack on OS ____ (Fill in: Windows, Mac, Linux, etc).
• I run Snowpack on Node.js v12+

Describe the bug

Seeing the following error running snowpack build with latest snowpack (3.1.1).
By tracing the code, it is possible related to this change:
Simplify. cleanup, enhance snowpack internals

[20:03:31] [snowpack] Error: /XXX/src/style/select/mixins.scss - Requested content ".css" but built .scss.
    at FileBuilder.verifyRequestFromBuild (/XXX/node_modules/snowpack/lib/index.js:112208:19)
    at FileBuilder.getResult (/XXX/node_modules/snowpack/lib/index.js:112415:42)
    at Object.loadUrl (/XXX/node_modules/snowpack/lib/index.js:131233:51)
    at async flushFileQueue (/XXX/node_modules/snowpack/lib/index.js:131625:28)
    at async build (/XXX/node_modules/snowpack/lib/index.js:131651:5)
    at async Object.command (/XXX/node_modules/snowpack/lib/index.js:131739:9)
    at async cli (/XXX/node_modules/snowpack/lib/index.js:132048:9)

To Reproduce

In my project, there's a pure scss mixin file. Inside runPipelineLoadStep(), it produces undefined result at this line. The undefined result value caused an ext mismatch in runPipelineLoadStep's return value.

So instead of

{
  '.css': {
    code: 'xxx'
  }
}

It produces

{
  '.scss': {
    code: 'xxx'
  }
}

This mismatch caused verifyRequestFromBuild() to fail as it was looking for a .css built content.

Adding a random CSS style inside the mixin file could bypass the issue.

Expected behavior

Snowpack build should support scss mixins.

[Danzo7]

Its could be caused by this :#3029

[cain-wang]

Thanks for the quick fix!

[Danzo7]

Thanks for the quick fix!

Your welcome but I'm not sure if its really the cause of this issue.
I closed that PR before merge cause I had no information or testing cases so if you can confirm that its work as intended with this ,also its better if you reopen this issue until we confirm that its solved.

[cain-wang]

That's a good point. I applied the change locally but that didn't seem to fix the issue.

I played with the snowpack code a bit and what worked for me is to force the code to enter this if logic here and default the undefined result to an empty string.

This is a very hacky change but just want to illustrate the logical path

            if (result === undefined || typeof result === 'string' || Buffer.isBuffer(result)) {
                const mainOutputExt = step.resolve.output[0];
                return {
                    [mainOutputExt]: {
                        code: result || '',
                    },
                };
            }

[radencode]

I'm running into the same error message above. Is anyone working on resolving this? Even if I downgrade to snowpack @3.0.0 (which used to work) it still throws that error.

[Findus23]

I applied the change by @cain-wang to the built js

diff --git a/node_modules/snowpack/lib/index.original.js b/node_modules/snowpack/lib/index.js
index df38480..a0dff21 100644
--- a/node_modules/snowpack/lib/index.original.js
+++ b/node_modules/snowpack/lib/index.js
@@ -54132,11 +54132,11 @@ async function runPipelineLoadStep(srcPath, { isDev, isSSR, isPackage, isHmrEnab
             });
             logger.logger.debug(`✔ load() success [${debugPath}]`, { name: step.name });
             config.validatePluginLoadResult(step, result);
-            if (typeof result === 'string' || Buffer.isBuffer(result)) {
+            if (result === undefined || typeof result === 'string' || Buffer.isBuffer(result)) {
                 const mainOutputExt = step.resolve.output[0];
                 return {
                     [mainOutputExt]: {
-                        code: result,
+                        code: result||'',
                     },
                 };
             }

and now it works fine.

[thom4parisot]

I face this issue, with a .scss file containing only Sass variables.

The file has to contain a CSS output to workaround this issue.

For example, this file will trigger the problem:

$main-color: #000;

html {

}

Whereas this one will not:

$main-color: #000;

html {
  font-size: inherit;
}

From my understanding of the patch and the behaviour of the workaround, a .scss file with an "empty output" — a blank string after optimization — fails to be converted as a .css file.

[themukhiddin]

I have the same problem. Empty mixins/variables files fails while building. Is there any solution?

[cain-wang]

@themukhiddin one work around I have was to add a random css style to the mixin file.

// adds a placeholder style to workaround snowpack build failure
// https://github.com/snowpackjs/snowpack/issues/2967
.snowpack-build-placeholder {
  display: none;
}

[sarended]

@cain-wang i had the same problem. this tempo-fix solved the problem for me. thank you.
waiting for bug fix from devs.

[drwpow]

From my understanding of the patch and the behaviour of the workaround, a .scss file with an "empty output" — a blank string after optimization — fails to be converted as a .css file.

This is indeed a current limitation of Snowpack. What should be the expected behavior here? If you’re importing something into Sass via @use to use within Sass, this isn’t an issue. So you can have variable-only files if you use them as normal Sass partials.

However, when you’re importing a Sass file into Snowpack, you’re telling Snowpack “build a .css file out of this in the final output,” and Snowpack generates an empty file and throws an error because it thinks the plugin failed. What should be the intended behavior? Should a blank .css file be included in the final build?

[drwpow]

I just realized in #3079 that it is a bug with scanning @import in Sass. I’ll leave this issue open to track. In the meantime, as a temporary workaround please use @use if you can (which Sass encourages over @import now anyway).

[drwpow]

I’m actually having a little trouble reproducing this on the latest version of Snowpack. Can anyone still reproduce on 3.3.7?

[Danzo7]

From my understanding of the patch and the behaviour of the workaround, a .scss file with an "empty output" — a blank string after optimization — fails to be converted as a .css file.

This is indeed a current limitation of Snowpack. What should be the expected behavior here? If you’re importing something into Sass via @use to use within Sass, this isn’t an issue. So you can have variable-only files if you use them as normal Sass partials.

However, when you’re importing a Sass file into Snowpack, you’re telling Snowpack “build a .css file out of this in the final output,” and Snowpack generates an empty file and throws an error because it thinks the plugin failed. What should be the intended behavior? Should a blank .css file be included in the final build?

@drwpow I believe that the actual problem is that the plugin API isn't enough to handle sass so you actually do have some exception for sass even in the snowpack core which actually make no sense for me, As for me you rather have sass fully supported on core or have a better plugin API to handle it properly (Fit with SASS API requirement) ,For me I see that having sass handled by default is a not a bad option as you already done that with TS . Why the plugin API is not enough you may ask, Cause to be able to take fully advantage of sass API you have to provide an input and output directory and then SASS API will take care of everything sass --watch app/sass:public/stylesheets , I try many approach to do this with snowpack plugin API but none of them was successful as even thought the plugin is capable to do everything from compiling to watch snowpack still want to do the work and sass API does not like if someone is using its file when watch, I would like to help in solving SASS issue in fact a month ago I stated this with you guys but we need a real discussion as Its requires a new strategy and you have to agree on that to find a solution.