Tweak webpack css-loader config to fix build errors

[b-kelly]

Describe your changes

Updates the css-loader settings in Webpack to fix build errors on my machine. I'm not entirely sure why the existing fix isn't enough, but I've added a more concise fix with a comment that also describes what's happening. I also updated importLoaders to the correct value while I was in there.

Side note: I'm not entirely sure why the filter rule is even necessary, since one would think that the /\.svg$/i rule above would kick in correctly and the pipeline would continue on without doing anything else, but it doesn't. 🤷

Partial error message

... (12 similar errors preceding)

ERROR in data:image/svg+xml;,%3csvg width=%27100%25%27 height=%27100%25%27 xmlns=%27http://www.w3.org/2000/svg%27%3e%3crect width=%27100%25%27 height=%27100%25%27 fill=%27none%27 rx=%275%27 ry=%275%27 stroke=%27%23000000%27 stroke-width=%278%27 stroke-dasharray=%277%2c 22%27 stroke-dashoffset=%270%27 stroke-linecap=%27square%27/%3e%3c/svg%3e
Module build failed: UnhandledSchemeError: Reading from "data:image/svg+xml;,%3csvg width=%27100%25%27 height=%27100%25%27 xmlns=%27http://www.w3.org/2000/svg%27%3e%3crect width=%27100%25%27 height=%27100%25%27 fill=%27none%27 rx=%275%27 ry=%275%27 stroke=%27%23000000%27 stroke-width=%278%27 stroke-dasharray=%277%2c 22%27 stroke-dashoffset=%270%27 stroke-linecap=%27square%27/%3e%3c/svg%3e" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "data:" URIs.
    at D:\code\Stacks-Editor\node_modules\webpack\lib\NormalModule.js:918:25
    at Hook.eval [as callAsync] (eval at create (D:\code\Stacks-Editor\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:16:1)
    at Object.processResource (D:\code\Stacks-Editor\node_modules\webpack\lib\NormalModule.js:915:8)
    at processResource (D:\code\Stacks-Editor\node_modules\loader-runner\lib\LoaderRunner.js:220:11)
    at iteratePitchingLoaders (D:\code\Stacks-Editor\node_modules\loader-runner\lib\LoaderRunner.js:171:10)
    at runLoaders (D:\code\Stacks-Editor\node_modules\loader-runner\lib\LoaderRunner.js:398:2)
    at NormalModule._doBuild (D:\code\Stacks-Editor\node_modules\webpack\lib\NormalModule.js:905:3)
    at NormalModule.build (D:\code\Stacks-Editor\node_modules\webpack\lib\NormalModule.js:1081:15)
    at D:\code\Stacks-Editor\node_modules\webpack\lib\Compilation.js:1400:12
    at NormalModule.needBuild (D:\code\Stacks-Editor\node_modules\webpack\lib\NormalModule.js:1407:32)
 @ ./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[2].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./node_modules/@stackoverflow/stacks/dist/css/stacks.css 15:37-399
 @ ./site/site.css.webpack[javascript/auto]!=!./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[2].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./site/site.css 4:0-246 14:26-59
 @ ./site/site.css
 @ ./site/index.ts 16:0-20

webpack 5.91.0 compiled with 13 errors in 5370 ms

PR Checklist

• N/A All new/changed functionality includes unit and (optionally) e2e tests as appropriate
• N/A All new/changed functions have /** ... */ docs
• I've added the bug/enhancement and other labels as appropriate

[netlify]

✅ Deploy Preview for stacks-editor ready!

Name	Link
🔨 Latest commit	d872046
🔍 Latest deploy log	https://app.netlify.com/sites/stacks-editor/deploys/663132e06586bd00082e2b35
😎 Deploy Preview	https://deploy-preview-316--stacks-editor.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[giamir]

Thanks @b-kelly. I am ok to merge these changes. I understand that since we don't use the sass-loader anymore importLoaders can be set to 1 instead of 2. Nicely caught.

The filter bit is only necessary for dev mode (npm start), in fact we could even consider extracting it to the webpack.dev.js file. Since we are importing the stacks.css for our standalone playground the css loader try to process all the svg inside stacks.css and return some errors. The previous filter was basically saying that anything coming from the stacks package should not be processed by the loader. The new one you created also end up fixing the issue since it is preventing any svg processing from css loader regardless of their location.

Here is the error when I run npm start without the filter rule

ERROR in data:image/svg+xml;,%3csvg width=%27100%25%27 height=%27100%25%27 xmlns=%27http://www.w3.org/2000/svg%27%3e%3crect width=%27100%25%27 height=%27100%25%27 fill=%27none%27 rx=%275%27 ry=%275%27 stroke=%27%23000000%27 stroke-width=%278%27 stroke-dasharray=%277%2c 22%27 stroke-dashoffset=%270%27 stroke-linecap=%27square%27/%3e%3c/svg%3e
Module build failed: UnhandledSchemeError: Reading from "data:image/svg+xml;,%3csvg width=%27100%25%27 height=%27100%25%27 xmlns=%27http://www.w3.org/2000/svg%27%3e%3crect width=%27100%25%27 height=%27100%25%27 fill=%27none%27 rx=%275%27 ry=%275%27 stroke=%27%23000000%27 stroke-width=%278%27 stroke-dasharray=%277%2c 22%27 stroke-dashoffset=%270%27 stroke-linecap=%27square%27/%3e%3c/svg%3e" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "data:" URIs.

For completness could you add in the PR description the stack trace of the issue you were getting in your machine. I am relatively confident is something Windows specific since neither Dan, I or the pipeline did catch it.

[b-kelly]

Good call on adding the error message. I added it to the original description (it matches yours exactly). I agree that this is likely either a Windows-only issue or perhaps unique to some setup I have on my machine. Either way, this new fix seems to work pretty well in all cases.