Module build failed: Error: resolve-url-loader: CSS error

[netdjw]

Hi,

I have a strange malfunction with resolve-url-loader. I have this webpack.config.js:

const ExtractTextPlugin = require('extract-text-webpack-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const webpack = require('webpack');
const path = require('path');

module.exports = {
  entry: ['./src/main.js', './src/main.scss'],
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'index.js'
  },
  devtool: "source-map",
  module: {
    rules: [
      {
        test: /\.scss$/,
        use: ExtractTextPlugin.extract({
          use: [
            { loader: 'css-loader', options: { minimize: true, sourceMap: true } },
            { loader: 'resolve-url-loader', options: { sourceMap: true } },
            { loader: 'sass-loader', options: { sourceMap: true } },
            
          ]
        })
      },

      {
        test: /\.(jpg|png|gif|ico|svg)$/,
        use: [{
          loader: 'file-loader',
          options: {name: '[name].[ext]', publicPath: 'img/', outputPath: 'img/'}
        }]
      },

      {
        test: /\.html$/,
        use: [
          {
            loader: 'html-loader',
            options: {
              interpolate: true
            }
          }
        ]
      }
    ]
  },
  plugins: [

    new ExtractTextPlugin({ // define where to save the file
      filename: 'style.css',
      allChunks: true,
    }),

    new HtmlWebpackPlugin({
      template: './src/main.html',
      filename: 'index.html'
    }),

    new webpack.ProvidePlugin({
      $: "jquery",
      jQuery: "jquery",
      "window.jQuery": "jquery"
    })

  ],
};

this is the package.json file:

{
  "name": "my-project",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build:watch": "webpack --watch"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "css-loader": "^1.0.0",
    "extract-text-webpack-plugin": "^3.0.2",
    "file-loader": "^2.0.0",
    "html-loader": "^0.5.5",
    "html-webpack-plugin": "^3.2.0",
    "node-sass": "^4.9.3",
    "resolve-url-loader": "^3.0.0",
    "sass-loader": "^7.1.0",
    "webpack": "^3.9.1"
  },
  "dependencies": {
    "bootstrap": "^4.1.3",
    "jquery": "^3.3.1",
    "owl.carousel": "^2.3.4",
    "popper.js": "^1.14.4"
  }
}

In the SCSS file I have this line what is the reason of the problem:

background-image: url('img/hero-slider-arrow.png');

I tried to change this line to this one:

background-image: url('data:image/png;base64,iVBORw0KGgoAAAA...==');

And in both case I got this error message:

ERROR in ./node_modules/css-loader??ref--0-1!./node_modules/resolve-url-loader??ref--0-2!./node_modules/sass-loader/lib/loader.js??ref--0-3!./src/main.scss
    Module build failed: Error: resolve-url-loader: CSS error
      source-map information is not available at url() declaration
      at file://d:\LARAVEL\Code\my-project\src\main.scss:7252:5
        at encodeError (d:\LARAVEL\Code\my-project\node_modules\resolve-url-loader\index.js:218:12)
        at onFailure (d:\LARAVEL\Code\my-project\node_modules\resolve-url-loader\index.js:175:14)
        at process._tickCallback (internal/process/next_tick.js:68:7)

Doublechecked the image file is on that path what is given. But if I use data:image/png solution... same error message. I don't understand what is the problem.

The other images working fine with similar url('img/filename.png') format.

Any idea?

[bholloway]

At first glance I see nothing wrong in your config. From memory that error implies the source map fails a lookup at that particular statement. But I am not sure that helps us. Data uris are not processed which implies the problem may not be that line. Try removing that line or at least that URL and make absolutely sure that’s the problem. Also try the debug option and see if that helps confirm your understanding of what urls are being considered. My apologies if you have already done this. Just my first thoughts.

[netdjw]

Thanks, I did these things, and nothing userful in debug mode.

I tried to turn off the sourceMap too, it isn't help.

[netdjw]

And one more thing: I use several background-images in several other files in this project, and those works fine. Those files hasn't any difference (except the file names of course).

I suspect a bug in resolve-url-loader, because this malfunction came out earlier but it was gone. I belived my colleges solved the problem, but now I asked them, and nobody solved it. Simply just gone. Strange.

[asbjornh]

I'm getting the same error after upgrading, but only on windows. on MacOS it builds just fine.

In my project i use import-glob. When I use a url() in the main SCSS entry point, this error doesn't occur when building on windows. It only happens when using url() in one of the files imported through import-glob. Don't know if that helps

Using resolve-url-loader@3.0.0, webpack@4.22.0 and sass-loader@7.1.0

[asbjornh]

(Also, downgrading to 2.3.1 solves the issue)

[bholloway]

"Simply just gone. Strange."

@netdjw I interpreted this as the problem went away. Is this still a problem with you? Is this a problem with your colleagues?

[bholloway]

Just reacquainting myself with the code. It looks like any url() will require the source-map to be valid at that location. See this code here.

This happens before we look further at the url() to see if we want to process it. So that would explain why @netdjw still gets the error with a data URI.

@asbjornh @netdjw I need some more data. Some ideas...

• I'm presuming you're working on closed source. Is there any chance you can construct a minimum failing example, open source?
• Can you try adjust-sourcemap-loader with debug mode in between sass-loader and resolve-url-loader. It will display the incoming source-map sources.

My current theory is that there is some upstream problem with the source-map sources. You should look to see it includes all the files you are compiling.

[asbjornh]

Yeah, I'll see if I get the time to create a minimum example during this week :)

[asbjornh]

Still working on narrowing this down, but it’s starting to look like an upstream error that’s not properly handled like you suggested. Right now I have a huge mixin (without any url calls), and when I remove it, the build runs fine. When it’s included, the build crashes with an error message from resolve-url-loader.

[asbjornh]

Ok this is quite weird. I've narrowed it down as far as I can I think. This setup fails with the above mentioned error on Windows 10, Node 8.11.4. The exact same setup builds fine on MacOS.

As you can see in style.scss below, there is a calc with a line break and extra parentheses inside of it. Remove the line breaks or the parentheses and the build succeeds. This is, of course, a really contrived example, but that calc originally contained some really verbose math. I use VS Code with autoFormat enabled, so a line break was inserted automatically.

I also tried downgrading to resolve-url-loader@2.3.1. The build succeeded (on Windows). The generated css file is at the very bottom of this post. Also, removing resolve-url-loader altogether makes the build succeed. When building without resolve-url-loader, the resulting css file is identical to the one with resolve-url-loader@2.3.1 in the build pipeline.

webpack.config.js

/* eslint-env node */
/* eslint-disable no-console */
const path = require("path");
const ExtractTextPlugin = require("extract-text-webpack-plugin");

module.exports = () => {
  return {
    devtool: "source-map",
    entry: { style: "./style.scss" },
    output: {
      path: path.resolve(__dirname, "dist")
    },
    module: {
      rules: [
        {
          test: /\.scss$/,
          exclude: /node_modules/,
          use: ExtractTextPlugin.extract([
            {
              loader: "css-loader",
              options: {
                importLoaders: 1,
                sourceMap: true
              }
            },
            { loader: "resolve-url-loader", options: { sourceMap: true } },
            { loader: "adjust-sourcemap-loader", options: { debug: true } },
            { loader: "sass-loader", options: { sourceMap: true } }
          ])
        },
        {
          test: /\.svg$/,
          use: { loader: "file-loader" }
        }
      ]
    },
    plugins: [new ExtractTextPlugin("[name].[chunkhash].css")]
  };
};

package.json

{
  "name": "example",
  "version": "1.0.0",
  "license": "MIT",
  "scripts": {
    "build": "webpack --mode=production"
  },
  "dependencies": {
    "adjust-sourcemap-loader": "^1.2.0",
    "css-loader": "^1.0.0",
    "extract-text-webpack-plugin": "4.0.0-beta.0",
    "file-loader": "^2.0.0",
    "node-sass": "^4.5.1",
    "resolve-url-loader": "^3.0.0",
    "sass-loader": "^7.1.0",
    "webpack": "^4.22.0",
    "webpack-cli": "^3.1.2"
  }
}

style.scss

body {
  font-size: calc(
    (1px)
  );
  background-image: url(./image.svg);
}

Shell output:

adjust-sourcemap-loader:
  ##path##\style.scss
        @ ##path##\node_modules\sass-loader\lib\loader.js??ref--4-4
    INPUT style.scss
 ABSOLUTE ##path##\style.scss

adjust-sourcemap-loader:
  ##path##\style.scss
        @ ##path##\node_modules\sass-loader\lib\loader.js?{"sourceMap":true}
    INPUT style.scss
 ABSOLUTE ##path##\style.scss
Hash: c18a8a717939eec50edc
Version: webpack 4.22.0
Time: 616ms
Built at: 2018-10-24 20:15:21
 2 assets
Entrypoint style = style.js style.js.map
[0] ./style.scss 1.69 KiB [built] [failed] [1 error]

ERROR in ./style.scss
Module build failed (from ./node_modules/extract-text-webpack-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/resolve-url-loader/index.js):
Error: resolve-url-loader: CSS error
  source-map information is not available at url() declaration
  at file://##path##\style.scss:4:3
    at encodeError (##path##\node_modules\resolve-url-loader\index.js:218:12)
    at onFailure (##path##\node_modules\resolve-url-loader\index.js:175:14)
    at <anonymous>
    at runMicrotasksCallback (internal/process/next_tick.js:121:5)
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)
    at runLoaders (##path##\node_modules\webpack\lib\NormalModule.js:286:20)
    at ##path##\node_modules\loader-runner\lib\LoaderRunner.js:364:11
    at ##path##\node_modules\loader-runner\lib\LoaderRunner.js:230:18
    at context.callback (##path##\node_modules\loader-runner\lib\LoaderRunner.js:111:13)
    at onFailure (##path##\node_modules\resolve-url-loader\index.js:175:5)
    at <anonymous>
    at runMicrotasksCallback (internal/process/next_tick.js:121:5)
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)
 @ ./style.scss

Generated css file with resolve-url-loader@2.3.1. The url points to the correct svg file in the build folder.

body {
  font-size: calc(
 (1px));
  background-image: url(7b56e1eab00ec8000da9331a4888cb35.svg);
}


/*# sourceMappingURL=style.9e5ee3d7a184f4b00938.css.map*/

[bholloway]

This is some really good work @asbjornh!

The resolve-url-loader@2.3.1 uses rework engine. So maybe also try resolve-url-loader@3.0.0 with engine:rework. That downgrades you from postcss back to rework but keeps the newly refactored/tested code.

🤔I guess the sources look normal. I suspect something to do with the different line break characters in Windows, CR and LF together unless I am mistaken.

I am wondering if @netdjw can point to similar code. Is the same problem you both have or 2 different problems.

For my part I will create a test case for this as soon as I get some time. In the mean time please let me know if the engine-only downgrade helps you for now.

[asbjornh]

Yep! engine: "rework" also solves this! :)

[bholloway]

@asbjornh as an outside chance take a look at the linefeed option in node-sass. You should be able to set this in sass-loader options. Default is lr so maybe try crlf (i.e. windows).

EDIT - although surely this must be something in postcss for this to not be an issue in rework.

[bholloway]

Looking at postcss tokenizer, it looks to me that CRLF (windows) would result in two line breaks instead of one.

But how this would make the source-map unusable I am unsure. 🤔

[ZebraFlesh]

I'm also encountering this issue on Windows:
OS: Windows 10
node: 10.13.0
webpack: 4.27.1
resolve-url-loader: 3.0.0

The engine: 'rework' option did resolve the issue, but passing linefeed: 'crlf' to sass-loader did not. I have an .scss file that contains a number of subsetted font definitions (regular, bold, and italic faces for each of a variety of subsets such as latin/latin-extended/cyrillic/greek/etc). The troublesome file is of this form:

@import '../variables';

@function get-type-path($filename) {
    @return $type-path + $filename;
}

// greek
@font-face {
    font-family: 'Lato';
    font-style: italic;
    font-weight: 400;
    src: local('Lato Italic'), local('Lato-Italic'),
        url(get-type-path('lato-italic-greek.woff2')) format('woff2');
    unicode-range: U+0370-03FF;
    text-rendering: optimizeLegibility;
}
// 23 similar @font-face definitions

Removing the line break from the src line doesn't seem to have any impact: resolve-url-loader still produces the same error, the same as originally reported:

    ERROR in ./src/baseStyle/_font-family.scss
    Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
    ModuleBuildError: Module build failed (from ./node_modules/resolve-url-loader/index.js):
    Error: resolve-url-loader: CSS error
      source-map information is not available at url() declaration
      at file://C:\Users\NOPE\myproject\src\baseStyle\_font-family.scss:65:3
        at encodeError (C:\Users\NOPE\myproject\node_modules\resolve-url-loader\index.js:218:12)
        at onFailure (C:\Users\NOPE\myproject\node_modules\resolve-url-loader\index.js:175:14)
        at runLoaders (C:\Users\NOPE\myproject\node_modules\webpack\lib\NormalModule.js:301:20)
        at C:\Users\NOPE\myproject\node_modules\loader-runner\lib\LoaderRunner.js:364:11
        at C:\Users\NOPE\myproject\node_modules\loader-runner\lib\LoaderRunner.js:230:18
        at context.callback (C:\Users\NOPE\myproject\node_modules\loader-runner\lib\LoaderRunner.js:111:13)
        at onFailure (C:\Users\NOPE\myproject\node_modules\resolve-url-loader\index.js:175:5)
     @ ./src/baseStyle/index.js 9:0-29
     @ ./src/components/type/headers/SectionHeader.js
     @ ./demo/src/components/IconDemo.js
     @ ./demo/src/routes.js
     @ ./demo/src/mount.js

The contents of src/baseStyle/index.js are straight forward:

import './_normalize.scss';
import './_font-family.scss';
import './_base.scss';
import '../components/type/typography.scss';

[bholloway]

@ZebraFlesh If you can setup a minimum breaking example repo then I can devote some time to debugging.

Earlier I tried to create a test case but I could not reproduce the problem on windows.

[michaelbeaumont]

I had this issue as well, the following change fixed it:

 .helpdesk-header {
   position: relative;
   width: 100%;
-  height: 450px;
   background-image: url('~alias/image.jpg');
   background-size: 100% auto;
+  height: 450px;
   text-align: center;
   .helpdesk-container {

Sorry, I don't have time at the moment for a minimal repo!

[lf-jeremy]

Passing linefeed: "crlf" to node-sass fixed this issue for my team members using resolve-url-loader@3.0.0 under Windows (same issue not present for us on OSX or Linux).

[michaelbeaumont]

Changing linefeed with sass-loader did not work for us.
I have a single SCSS file (explicitly showing crlf endings):

.planner-workspace-label {^M
   transition: width .3s ease, width .3s ease,^M
          left 200ms,^M
          background-color 0.2s ease;  ^M
   background-image: url('~alias/image.png');^M
}^M

When postcss and resolve-url-loader/lib/engine/postcss.js see this content, after it's been through sass-loader, resolve-url-loader chokes on the following declaration:

  "declaration": {
    ...,
    "source": {
      "start": {
        "line": 5,
        "column": 3
      },
      "input": {
        "css": ".planner-workspace-label {\r\n  transition: width .3s ease, width .3s ease,\r left 200ms,\r background-color 0.2s ease;\r\n  background-image: url(\"~alias/image.png\"); }\r\n",
     },
     value: "url(\"~alias/image.png\")"
     ...

Note the 2 \r carriage returns not accompanied by a newline in the input.
It appears this is libsass's doing.

Unfortunately, params.sourceMapConsumer doesn't contain any mapping with generatedLine = 5, only until generatedLine = 3 and so we throw the error.

The postcss tokenizer correctly? recognizes a single \r as a line break, the generated mappings seem not to however.

[bholloway]

@michaelbeaumont I would not expect to see naked \r in a file using \r\n scheme, but I put that down to my ignorance. What platform/editor are you using?

[michaelbeaumont]

There are no naked \r characters in the file initially, the file contains only normal \r\n sequences (the initial snippet I posted, where ^M = \r).
The naked \rs appear to be from libsass, because running the file manually through node-sass manually also produces this output, where the \r\n pairs inside the CSS values (after the commas), i.e lines 2 and 3 are reduced to \r.

I might be overlooking something obvious, but it seems very much like a libsass issue.

Anyway, I stopped investigating further because this led me to the fix (for this specific case at least) of just removing the line breaks after the commas.

[bholloway]

Sorry @michaelbeaumont I see now that you did originally say that.

"It appears this is libsass's doing."

[bholloway]

To summarise

There is some issue with multiline declarations.

• @netdjw originally implied a problem with base64 data URI (not multiline?).
• @asbjornh shows line-break and/or parenthesis imply a problem.
• @michaelbeaumont shows a possible sensitivity to preceding declarations.
• Simplifying the declaration (removing the line breaks or parenthesis) worked for @asbjornh @michaelbeaumont but does not work for @ZebraFlesh.
• Changing node-sass linefeed option worked for @lf-jeremy but did not work for @ZebraFlesh @michaelbeaumont.
• @michaelbeaumont shows naked \r coming from libsass (where not in source files).

The workarounds

• @netdjw is no longer experiencing the problem but did not actively fix it.
• @ZebraFlesh @asbjornh has downgraded to engine: rework.
• @lf-jeremy is using the linefeed option by way of sass-loader.

Remaining

• bugfix Unable to reproduce - Waiting for minimum breaking example.
• enhacement Add link to node-sass linefeed option in the readme.md.
• enhancement Think about an architecture change here such that unprocessed statements don't require source-map. This is not a fix.

[bholloway]

I've synthesised an orphan CR in tests and it (correctly) fails in both MacOS and Windows.

That has allowed me to draft a possible fix in #108.

I won't publish this pre-release because really I am not sure we are on the right track. It remains to be see that this fixes the actual problem.

So please install bholloway/resolve-url-loader#remove-orphan-CR-character and let me know.

[laTruffe79]

I've been forced to rollback to version 2.0.2, maybe it's a dependency problem with laravel-mix 4.0.15 ? Le jeu. 21 mars 2019 à 22:07, Ben Holloway <notifications@github.com> a écrit :

…

Sorry been completely slammed with work. Have not yet investigated further the root cause. Please let me know if this is immediately needed. Otherwise I’ll stick to the plan above. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHnRsBkize4CT99ZMVU6J9PITKopfMnTks5vY_R3gaJpZM4XwFg8> .

[bholloway]

I moved the breaking example to resolve-url-loader-107.

The style.scss was committed to the repo with CRLF but I think that is incidental.

As promised by @asbjornh this does pass in MacOS and fail in Windows (for me).

Analysis

On checkout in windows it appears with CRLF only (0D0A).

> Format-Hex style.scss

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   62 6F 64 79 20 7B 0D 0A 20 20 66 6F 6E 74 2D 73  body {..  font-s
00000010   69 7A 65 3A 20 63 61 6C 63 28 0D 0A 20 20 20 20  ize: calc(..
00000020   28 31 70 78 29 0D 0A 20 20 29 3B 0D 0A 20 20 62  (1px)..  );..  b
00000030   61 63 6B 67 72 6F 75 6E 64 2D 69 6D 61 67 65 3A  ackground-image:
00000040   20 75 72 6C 28 2E 2F 69 6D 61 67 65 2E 73 76 67   url(./image.svg
00000050   29 3B 0D 0A 7D                                   );..}

Running stand alone sass compile.

> npx node-sass style.scss output.css

Interestingly the line feeds come out as LF (0A). But we do get the orphan CR (0D) we're looking for.

> Format-Hex output.css

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   62 6F 64 79 20 7B 0A 20 20 66 6F 6E 74 2D 73 69  body {.  font-si
00000010   7A 65 3A 20 63 61 6C 63 28 0D 20 28 31 70 78 29  ze: calc(. (1px)
00000020   29 3B 0A 20 20 62 61 63 6B 67 72 6F 75 6E 64 2D  );.  background-
00000030   69 6D 61 67 65 3A 20 75 72 6C 28 2E 2F 69 6D 61  image: url(./ima
00000040   67 65 2E 73 76 67 29 3B 20 7D 0A                 ge.svg); }.

With appropriate settings for linefeed.

> npx node-sass --linefeed crlf style.scss output.css

The line feeds come out as CRLF (0D0A). But we still get the orphan CR (0D) we're looking for.

> Format-Hex output.css

           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000   62 6F 64 79 20 7B 0D 0A 20 20 66 6F 6E 74 2D 73  body {..  font-s
00000010   69 7A 65 3A 20 63 61 6C 63 28 0D 20 28 31 70 78  ize: calc(. (1px
00000020   29 29 3B 0D 0A 20 20 62 61 63 6B 67 72 6F 75 6E  ));..  backgroun
00000030   64 2D 69 6D 61 67 65 3A 20 75 72 6C 28 2E 2F 69  d-image: url(./i
00000040   6D 61 67 65 2E 73 76 67 29 3B 20 7D 0D 0A        mage.svg); }..

Conclusion

Certainly looks to be a bug in SASS. Sure the example breaks in webpack but the root cause is reproducible in node-sass CLI.

But this is simply reproducing the excellent work of others above.

[bholloway]

So the removeCR option is released as resolve-url-loader@3.1.0. Thanks to everyone who tested the beta.

The libsass bug is apparently fixed master as of a few days ago. At some time we will see a node-sass release. But I think we will keep this removeCR option, at least until the next major release.

Sorry for the delay. Its been a pleasure working with you all on this.

[fiskhandlarn]

Can someone please help me how to add the option removeCR when using import-glob-loader? Current rule in my webpack.mix.js:

      {
        test: /\.scss$/,
        loader: 'import-glob-loader',
      },

@asbjornh you mentioned import-glob ..?

[fiskhandlarn]

Anyone? Pls help X)
@asbjornh

[asbjornh]

Dude, just read the comments... Already answered

[fiskhandlarn]

@asbjornh DUDE, the comments does NOT answer my question about using import-glob-loader. I wouldn't ask if it worked, would I?

[bholloway]

Okay lets discuss on #125 and keep this particular issue closed.

[erwinfrias]

I had the same probleme with resolve-url-loader: CSS error and I found the fix adding removeCR and sourceMap:

{ loader: 'resolve-url-loader', options: { removeCR: true, sourceMap: true } }

[esynaps]

With Webpack Encore : (Version ^0.28.0 required)

    .enableSassLoader((options) => {}, {
        resolveUrlLoaderOptions: {
            removeCR: true
        }
    })

[zehawki]

This is not to open this issue, but just to document my findings. I also hit this issue after doing a yarn upgrade. To resolve, I used the excellent instructions given here: https://npm.runkit.com/resolve-url-loader

Diagnosis

Run a stand-alone sass build npx node-sass index.scss output.css
Use a hex editor to check line endings Format-Hex output.css (I used the superb https://hexed.it/ie.html)
Expect 0DOA (or desired) line endings. Single 0D confirms this problem.

My output CSS of 11K LOC threw up a few instances of standalone 0D (without ODOA). This turned out to be the issue:

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen,
 Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;

[barbala4o]

I had the same probleme with resolve-url-loader: CSS error and I found the fix adding removeCR and sourceMap:

{ loader: 'resolve-url-loader', options: { removeCR: true, sourceMap: true } }

where did you add these lines exactly??

[dospuntocero]

same question... just wondering where you add that

[M-Matin-dev]

Not a permanent solution but this post on stackoverflow helped me to serve and build my project.

I had this same error. To fix this, I had to navigate to 

- node_modules/resolve-url-loader

 open 

- index.js

 and under `var options` change `removeCR` from "false" to "true".

same question... just wondering where you add that

[hmawla]

Well...
Just pointing to the existence of this package:
https://www.npmjs.com/package/resolve-url-loader-with-removecr

[ZebraFlesh]

Well...
Just pointing to the existence of this package:
https://www.npmjs.com/package/resolve-url-loader-with-removecr

1. I have no idea where the source code is for that module, since the info in the NPM registry points back to this package.
2. The 3.1 release of this package included the removeCR option: https://github.com/bholloway/resolve-url-loader/blob/v4-maintenance/packages/resolve-url-loader/docs/troubleshooting.md#windows-line-breaks

[bholloway]

Furthermore in resolve-url-loader@4 the removeCR option is activated by default on windows OS now.

So there should not be a use case for resolve-url-loader-with-removecr.

[Johnoris]

I had the same issue I just uninstalled node-sass and installed sass instead and it now works fine