publicPath backward compatibility issue in 0.11.1

[wujekbogdan]

I've just upgraded from 0.10.1 to 0.11.1

This is how one of my file-loader entries looked like before the upgrade.

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

• I keep images under the ./src/img/ directory
• SCSS is compiled from ./src/scss/app.scss to ./dist/css/app.css
• The target images directory is ./dist/img/

So URL in the CSS file must look like url(../img/image-file.jpg)

Before the upgrade it was OK. But after upgrade, URLs started to look like url(../img/img/image-file.jpg) (notice the additional /img/).

So I had to change the publicPath entry from publicPath: '../img' to publicPath: '../'

So now, my config looks like:

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

So, this is a breaking change, it should be either fixed or documented (if it's intentional).

---

webpack 2.3.2, macOS Sierra, node v7.7.2

[jcdickinson]

I can't use it in this state at all. ASP.Net uses a directory called wwwroot to contain static content. To support sourcemaps, my source clientside scripts and less are under wwwroot. This naturally leads to the following configuration:

options: {
    name: '[name].[ext]',
    publicPath: '/data/',
    outputPath: 'wwwroot/dist/data/'
}

This results in the following in my final CSS (the value I'm looking for is just url(/data/icons.eot)):

foo {
    src: url(/data/wwwroot/dist/data/icons.eot)
}

The only viable workaround is to revert to 0.10.1 (thanks @wujekbogdan), getting these results from 0.11.1 seems completely impossible (I've tried using ../ as described above).

[michael-ciniawsky]

Looks like outputPath/publicPath gets both applied/'joined', which would clearly be a bug :)

[michael-ciniawsky]

@wujekbogdan @jcdickinson Could someone try changing options.outpuPath && options.publicPath and see if there's a pattern?

[AndreKR]

What do you mean, pattern?

To me it seems that with 0.11.1 the public path (the thing that eventually gets appended to webpack_public_path) is always publicPath+outputPath+name (wrong) while with 0.10.1 it was publicPath+name (better*).

Do you mean you found a case where the outputPath is not wrongly appended in 0.11.1?

_{* I'm writing "better" because personally I would prefer to have the publicPath completely independent from the name that is logged and supporting the same placeholders.}

[praveenperera]

Yup I just encountered this bug too, took me a while to figure out what was going on. My code is as follows.

        query: {
          name: "[name].[ext]",
          outputPath: "../static/images/",
          publicPath: "../images/"
        }

On 0.10.1 it works fine because the url is resolved to images/whatever.jpg but on 0.11+ it resolves to ../images/../static/images/whatever.png

And using an absolute path as the publicPath doesn't fix it either

url(http://localhost:4000/images/../static/images/whatever.jpg)

As @AndreKR stated above it seems like like publicPath = publicPath + outputPath when instead it should be publicPath = publicPath

[alexander-akait]

@wujekbogdan Is the problem still there? Did comment #140 (comment) help your to solve problem?

[alexander-akait]

Right now file-loader@1 is stable version. For a long time no one tried to solve this problem, so I close it. Thanks everyone!