How to debug resolve-url-loader cannot operate ?

[chollier]

Hey ! I'm getting some :

ERROR in ./~/css-loader!./~/resolve-url-loader?fail!./~/sass-loader?sourceMap!./src/css/application.scss
resolve-url-loader cannot operate: source-map error cannot establish a common base path for all sources in the incoming source-map
webpack: bundle is now VALID.

My loaders look like that :

  module: {
    loaders: [
      { test: /\.jsx.coffee$/, loaders: ["jsx?harmony", "coffee"], exclude: /node_modules/ },
      { test: /\.coffee$/, loader: "coffee-loader", exclude: /\.jsx.coffee$|node_modules/ },
      { test: /\.js$/, loaders: ["babel-loader"], exclude: /node_modules|rollbar|mixpanel/ },
      { test: /\.json$/, loader: "json" },
      { test: /\.css$/, loaders: ["style", "css", "resolve-url?fail"] },
      { test: /\.scss$/, loaders: ["style", "css", "resolve-url?fail", "sass?sourceMap"] },
      { test: /\.woff2?$|\.ttf$|\.eot$|\.svg$|\.png$|\.jpg$/, loader: "file" }
    ]
  },

And I have :

  devtool: "source-map",

I'm not quite sure how to debug this ?

[chollier]

Also,

I should specify that i'm transitioning from grunt build sass to webpack handling that.
It's important to note that the CSS output i'm getting from require("../../css/application.scss"); is good : my app look the same.

[bholloway]

The resolve-url-loader relies on source map information from the preceding sass loader in order to correctly resolve relative url() statements.

If the source-map sources are relative then it needs to convert then to some absolute path. For sass-loader the source-map sources are usually relative to the Webpack output directory. However this is not necessarily the case for other css transpilers.

The resolve-url-loader gets around this ambiguity by searching for the given source-map sources in your project (starting with, but not limited to, the Webpack output directory). When it finds a source it notes what base path was needed to get that source. If the base-path is the same for all sources then everything is consistent.

If the base-path is inconsistent then it will throw this error.

Without having access to your project I will need to think about how we can debug this one.

If you want to hack some code then try logging value at sources-relative-to-absolute.js#L67 and let me know what you get.

[chollier]

Hey,

I was able to solve that issue using the extract text plugin, somehow the source maps errors started popping.
I'm now using that :

{ test: /\.scss$/, loader: ExtractTextPlugin.extract("style", "css?sourceMap!resolve-url?sourceMap!sass?outputStyle=expanded&sourceMap=true&sourceMapContents=true") },

[bholloway]

@chollier I also use the ExtractTextPlugin myself. However I've been scratching my head as to how it would effect the issue.

Since you last posted is the problem still solved or has the error returned?

If you temporarily remove the plugin, and use css?sourceMap!resolve-url?sourceMap!sass?outputStyle=expanded&sourceMap=true&sourceMapContents=true do you still get the problem?

[chollier]

I just tried and I do not. I was in the middle of a big refactoring so i'm not quite sure exactly what solved the issue. However I believe I fixed part of the problem by updating node-sass, previously it was error-ing because the version of libsass or node-sass I was using wasn't supporting single-line comments or something like that.

[meta-meta]

@bholloway I'm seeing this problem. following your advice

If you want to hack some code then try logging value at sources-relative-to-absolute.js#L67 and let me know what you get.

what would it mean if on line 75, adding

console.log(value);

produces

/
d:\

the root directory of my webpack project is d:\Projects/project
I am running Windows and my colleagues running on Mac do not experience this issue.

I am running into this error only on webpack-dev-server. webpack works fine

update: I'm seeing defaultBasePath passed to sourcesRelativeToAbsolute(sources, defaultBasePath, limit) is / and I'm not sure why that is as the output.path in my webpack.config is pointing to d:\Projects\project\build

my dirty hack for now is to add this as first line of sourcesRelativeToAbolute: defaultBasePath = 'd:\\';

[bholloway]

@meta-meta sorry for not getting back to you sooner.

Seems like a bug. I will look into it. Let me move this to a new issue.

[toverux]

Hello,

I've got a similar problem with resolve-url-loader, but I also don't know when things broke since I did a big refactoring.

I get exactly the same errors for each scss files in my application:

WARNING in ./src/ui-components/entities-table/entities-table.scss
  resolve-url-loader cannot operate: source-map error
  EACCES: permission denied, scandir '/root'

WARNING in ./src/ui-components/input-error/input-error.scss
  resolve-url-loader cannot operate: source-map error
  EACCES: permission denied, scandir '/root'

etc...

The /root the error mentions is the /root folder of my Linux filesystem.
Let me know if I can do anything to help you.

[agelenava]

@toverux based on your log it seems like it doesn't have permission
EACCES: permission denied
try to run it under root or change the permission.

[toverux]

Yes, I know that that's a permission problem. But resolve-url-loader has absolutely nothing to do in /root. Don't put sudo before any command that throws a permission error, that just doesn't solves problems.

[bholloway]

@toverux I am afk for at least this week but I can offer advice. You don't want the search to get outside your project directory. Period. That said, don't choose a structure that is not fully contained within your webpack `root`. To do so can work but trends to be problematic. Personally I NPM link subprojects. If you suspect your refractor then just make sure it wasn't NPM by checking out your old code and doing a fresh install. Then you can be sure either way. If you can isolate to a change delta that that is your best lead. I don't recall what if any debug facilities there are but (worst case) try to follow the file search routine. Best of luck.

[toverux]

I have no files outside of my project directory :)

I came back to an old version of the project, way before that problem popped and.. I still have it. I deleted node_modules, but nothing to do.

This time, it appears on the office PC. It tries to access /lost+found, exactly like on my PC, and if I delete lost+found, il falls back to another lost+found of another partition. If I delete all lost+founds, then it tries the famous /root. It seems that some operation caused a persistent side effect on my machines, but I really don't know what. But I can assure you that I did nothing special. Since you're not available now, if I have some time, I could try to trace resolve-url-loader to find where and why it likes lost+founds so much.