Webpack和Sass正确处理后台：url（）图像但是当与webpack-dev-server一起使用时找不到它

Question

I am using Webpack 2 and webpack-dev-server together with Sass loader, actual configuration:

{
    test: /\.scss/,
    loaders: [
        "style",
        { loader: "css", query: { modules: false, sourceMap: true } },
        { loader: "resolve-url" },
        { loader: "sass", query: { sourceMap: true } }
    ]
}

This works quite well and the image referenced in background: url() is processed by webpack and also replaced in the style for something like background-somehash.jpg , this file can be accessed by typing http://localhost:8080/background-somehash.jpg . It also works when I provide whole url (including localhost) in a style background definition using developer tools...

The only thing that don't work is the original css produced by webpack which looks like background: url(background-somehash.jpg) . I also tried various urls like ./ , ../ , ../../ or ./images/ to try out if root was set somehow differently. What I don't get is that the file is readily available at the root...

EDIT: When used together with extract-text-webpack-plugin which extracts styles into separate real styles.css file it works just fine. The question is why it doesn't work when final css is being served from javascript bundle ?

CLARIFICATION: Everything is referenced correctly, the image is available, it all works when I extract css into separate file using extract-text-webpack-plugin it just doesn't work when the completely same css is served from bundle.js which is then referenced in the index.html like <link href="blob:..." rel="stylesheet">

Answer 1

Things you should check:

Is the referenced image recognized by webpack?

Just delete the image and check if the webpack build fails. If that's the case, it is not an issue with your loader configuration.

Check the requested URL with your browser developer tools

If the request is terminated with a 404:

• Check if output.publicPath (webpack) / contentBase (webpack-dev-server) point to the same location. This is from the browser's perspective (=no absolute file paths)

• If you're using a <base> -tag, you need to ensure that it does replace the base URL correctly.