Works in debug but not in production

[AaronLayton]

I am having with getting this to run in production

{
    test: /\.scss$/,
    use:  ExtractTextPlugin.extract({
        fallback: 'style-loader',
        use: [
            {
                loader: 'css-loader',
                options: {
                    sourceMap: true,
                    url: true
                }
            },
            "resolve-url-loader",
            "sass-loader?sourceMap"
        ]
    })
}

My folder structure is as below

/content/css/main.scss /content/css/bem/myfile.scss /content/img/download.svg

myfile references an svg with background-image: url('../../img/downloaded.svg');

the resolve-url-loader correctly fixes the reference when using the straight webpack command but if I use webpack -p it can no longer find the correct file

[Spetnik]

Same here. Using webpack 3.11.0. webpack -d works fine. webpack -p produces tons of Module not found: Error: Can't resolve... messages

[Spetnik]

Update: it seems that by moving the lines that reference the urls to a point later in the file, the issue is resolved. Build still takes forever though...

[ganyusheng520]

the same in webpack 3.10.0

[bholloway]

@AaronLayton I now have a branch where I have developed (long overdue) e2e test. I will setup your use-case and maybe ask some more questions.

@Spetnik it is possible that resolve-url-loader is making a costly file search using the "magic". Set debug = true to see the extent of the search.

If you don't normally need the search "magic" then in geneal you will want attempts = 1. Certainly attempts should be a small value.

In Webpack 1 days when I was dogfooding this I found that I had to avoid production mode because I wanted development-production parity. I was minifying in development and using source-maps. Back then production mode just implied plugins and other configuration that you could add explicitly yourself. That said I know it is mainstream to use production mode so am happy to work this out.

[bholloway]

@AaronLayton covered this in e2e tests but can't reproduce. Could you please submit a small example project that we can look at in detail.

[cholnhial]

@Spetnik You were right moving the troublesome stylesheets around fixes the issue. I moved the stylesheets that were causing the error all the way down in the file.

[bholloway]

So historically -p has been a shortcut for some other options. See webpack 3 as an example (since webpack 3 was mentioned).

If I recall correctly there was a problem with certain versions of sass-loader when minimising the output css. That said I am using node-sass@^4 in the e2e tests and I do not have to do anything special to make that work.

Can ppl pls state their node-sass version, if only to eliminate that angle.

[bholloway]

I am linking #32 in case it is relevant.

[cholnhial]

@bholloway my node-sass version is 4.5.3.

[bholloway]

Could you please submit a small example project that we can look at in detail.

I am blocked on this. Can anybody supply an minimum example?

[bholloway]

Please refer to #97 as version 3 may help any open issues.

[bholloway]

I'm going to close this ageing issue because we have a new version 3.0.0 which (e2e testing confirms) is much better.

Please open a fresh issue for any ongoing problems and link to this one as needed.

I'm not opposed to reopening this issue but certainly lets talk with respect to the new version.

[donnysim]

For anyone still having this problem (also with v3 and webpack 4), I've found that it occurs with libass, moving to node-sass implementation solved the problem for me.

{
  loader: 'resolve-url-loader',
},
{
  loader: 'sass-loader',
  options: {
    sourceMap: true,
    implementation: require('sass'),
  },
},

though you might have to fix other problems as node-sass is updated while libass is stale and ignores most of the errors and misses new features like @use.

Can't reproduce this issue in a clean project to provide a demo and was unable to find the problem while debugging.