External scss styles do not work with manually enqueued standalone processors

[grundmanise]

Describe the bug
External scss styles do not work with manually enqueued standalone processors:

const preprocess = [
  scss({
    implementation: nodeSass
  }),
  postcss({
    plugins: [autoprefixer()]
  })
];

Logs

packages/client/src/components/Nav.svelte
Module build failed (from ./node_modules/svelte-loader/index.js):
Error: ParseError: Selector is expected (1:34)
1: <style lang='scss' src='Nav.scss'>$test: 1;
                                     ^
2:
3: nav {

To Reproduce
Repo: https://codesandbox.io/s/svelte-preprocess-bug-example-jrml4?file=/src/components/Nav.svelte
Run yarn dev. If you would inline Nav.scss contents it would work as expected.

Expected behavior
External scss stylesheet would be parsed correctly.

Information about your project:

• svelte-preprocess: 3.9.7

• Webpack

[kaisermann]

Hey @grundmanise 👋 Been trying to find out what's happening here for 2 hours and finally found something. There are mainly two issues here:

• the compiler doesn't pass the preprocessed result to subsequent preprocessors, so the scss and postcss preprocessors each receive a copy of your style as it is in your component. Ok, easy fix IN THEORY.
• every processor exported by svelte-preprocess looks for a src='...' attribute, which causes the postcss preprocessor to use the Nav.scss content, instead of the preprocessed result from previous preprocessors. However, the biggest issue is that the attributes object is shared between all preprocessors.

I've started a patch for the svelte compiler to fix these 2 issues, but I'm stuck on how to solve the second one. Even if the postcss preprocessor receives the updated content, it will always look for the src="..." attribute first.

The first obvious (and possibly naive) solution that came to my mind is allowing preprocessors to modify the attributes object, so, for this case, the scss preprocessor would be able to remove the src="..." before passing it to postcss.

edit:

My bad, the compiler does indeed pass the preprocessed content to subsequent preprocessors. Just got confused by a little variable shadowing.

The second fix that comes to mind is to make each preprocessor aware of what kind of files they can import via the src attribute.

[grundmanise]

Hey @kaisermann 👋 Thank you for the investigation 👍 I didn't get a chance to go through the code, but can't we just state that if preprocessed content is being passed to the compiler it should not read src attribute? Basically the preprocessed in-memory content would always win.

[kaisermann]

@grundmanise Yeah! That's similar to what @halfnelson suggested in the discord server. If the content being passed is non-empty, the processors will just ignore the src attribute. I'll probably fix it soon 😁

[kaisermann]

There ya go, fixed in v3.9.8 🎉