Css-loader: sourceMap css does not function for background-image (maybe stylus-loader issue)

Created on 17 Dec 2014  路  29Comments  路  Source: webpack-contrib/css-loader

So this issue is bizarre and I hope I can make an example that does this.

I successful got sourceMaps to work with stylus-loader with
{ test: /\.styl$/, loader: 'style!css?sourceMap!stylus' }

However when ?sourceMap is enabled all our background url('whatever/sprite.png') no longer work. When the ?sourceMap is removed all is well.

I will make an example repo when I get the chance. Also let me know if this should be an issue on stylus-loader instead.

As for more info the css produced are identical except that sourcemap css is redirected via @import some url. The computed CSS reported by Chrome Debugger is identical, but using (Chrome Extension) CSSViewer reports different processed CSS. Which shows the missing sprite.

Also this problem exists in Firefox as well so I do not think it is a chrome issue.

Bug

Most helpful comment

This still seems to be an issue. Using webpack v1.12.14, css-loader v0.23.1. When sourcemaps are on, background-images will not work. Setting output.publicPath to a full url does nothing to resolve the problem.

All 29 comments

The problem is that DataUrls cannot download resources... (The stylesheet is embedded as DataUrl to append the SourceMap)

As workaround you could include every image as DataUrl (with the url-loader instead of the file-loader)...

I'll try to find a better solution...

Thank you.

I'll try to find a better solution...

URL.createObjectURL + Blob + sourceMappingURL does work.

Its been a while; how would this look in the config?

style-loader!css-loader?sourceMap

we are using stylus-loader and all the url paths are not resolved, if the stylus file was called via another module via ~myModule.

With this settings for the stylus-loader it's working: ?{"resolve url": true}

I just came across the same issue where background images from css don't work because of the paths, when using sourcemaps, css-loader and file-loader in dev mode with webpack-dev-server.

For now I've simply disabled sourcemaps, but was there a better fix? style-loader!css-loader?sourceMap was mentioned but this is exactly what's breaking for me.

I think a workaround is to use an absolute URL as output.publicPath.

113 related; tried the pubicPath still didn't work.

This issue is also failing with fonts as well. They are being declared as they cannot be decoded in chrome or firefox. Oddly it works fine in safari.

Is there still no fix for this? Specifying an absolute path for output.publicPath does not seem to work for background-image when sourcemaps are used css?sourceMap in the loader.

Specifying an absolute path for output.publicPath does not seem to work for background-image when sourcemaps are used css?sourceMap in the loader.

Specify an absolute URL (http://...) instead of an absolute path (/...).

Right I am using publicPath: 'http://localhost:9999/' but when I inspect the location of the background-image its chrome-devtools://devtools/public/img/ajax-loader.gif. The original path is /public/img/ajax-loader.gif

This only happens when sourcemap is on.

for me too :(

Weird. Running into this too when output publicPath isn't set to the full URL.

Setting output.publicPath to an absolute URL should fix the issue, see style-loader README.

This still seems to be an issue. Using webpack v1.12.14, css-loader v0.23.1. When sourcemaps are on, background-images will not work. Setting output.publicPath to a full url does nothing to resolve the problem.

I can confirm that setting output.publicPath to a full url fixed the problem for me. My webpack server is hosted on port 5000, my related chunk of config looks as follows:

output: {
  publicPath: 'http://localhost:5000/',
},
module: {
{
    test: /\.styl$/,
    exclude: /node_modules/,
      loader: 'style!css?sourceMap!stylus?resolve url',
}, {
    test: /\.css/,
    loader: 'style!css?sourceMap',
  }
}

I write Stylus as follows:

// using file-loader explicitly here as I have svg-inline-loader managing .svg files in config
background-image url('~!file!assets/patterns/grey.svg')

It produces following output in generated css:

background-image: url(http://localhost:5000/95d465435d15b4852261c1b7315c90ba.svg);

which is proprely seen and parsed by the browser.
This is the only workflow that works for me. Hope this helps someone.

Has this been fixed in another ticket? I can't seem to find anything.

Still facing this problem. I dont want to set an absolute URL like http://... So only thing i can do is to remove the sourceMap

I am having issues with this as well, hoping for a solution that doesn't involve setting an absolute url on publicPath. Webpack is pretty much useless as build tool in your development workflow if you cannot use source maps to understand what styles are needing to be adjusted when viewing an elements styling.

Only solution that worked for me was to use sourceMaps with extract-text-webpack-plugin to extract css to own file + change devtool from "eval-source-map" to "source-map".

Only problem now is that hot reload is veery slow because of high quality source maps. So this is viable only for staging or production environment :)

Has this been resolved in the meantime?

I faced this issue as well, I disabled source map as absolute URL in public path does not fix the problem.

Hi I'm still having this issue. I was not able to resolve it by setting output.publicPath to an absolute URL either :(

here is a repository I made demonstrating the problem: https://github.com/mhfowler/Webpack-Example/

When I remove sourceMap from the css-loader there is no issue.
But with sourceMap, images set for background-image via url() are unable to load.

Any help is appreciated, or if you can identify in my webpack config that would be great.
Here is a link to my webpack config: https://github.com/mhfowler/Webpack-Example/blob/master/webpack.config.babel.js

@mhfowler The same.

@mhfowler Same issue. enable css module, background-image via url() are unable to load with url-loader, but DataUrl can work.

Was this page helpful?
0 / 5 - 0 ratings