Wrong URL for background images

[amlbar]

Bug report

The css-loader does not give me the correct url for my css build like when using background: url(***);. The url is being hashed automatically even setting it in file-loader option to not use a hash for the filename. I also set the file-loader option emitFile: false; and then the finished build has still emitted a file for that url. This bug exists since css-loader@6.0.0.

Actual Behavior

The url in my Sass file is in this form:

background: url(../../assets/img/shapes.svg);

The output url is converted to something like:

background: url(../86b5f32909e54c79331e.svg);

And the build emitted a new file 86b5f32909e54c79331e.svg with the content inside it like export default "../img/shapes.svg";

Expected Behavior

The url in my Sass file is in this form:

background: url(../../assets/img/shapes.svg);

The output url should be converted to this:

background: url(../img/shapes.svg);

And there should be no additional images created or emitted after build.

How Do We Reproduce?

You can clone my sample project with minimal code in it here in https://github.com/amlbar/webpack-build-css-with-bug and run on your local machine. For this project, you need to manually change the js and css source in the index.html. (It is handled automatically by django webpack loader in my real project)

Please paste the results of npx webpack-cli info here, and mention other relevant information

System:
    OS: Linux 4.4 Ubuntu 18.04.5 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
    Memory: 1.67 GB / 11.90 GB
Binaries:
    Node: 12.16.3 - ~/.nvm/versions/node/v12.16.3/bin/node
    Yarn: 1.22.4 - ~/.nvm/versions/node/v12.16.3/bin/yarn
    npm: 7.24.0 - ~/.nvm/versions/node/v12.16.3/bin/npm
Packages:
    clean-webpack-plugin: ^4.0.0 => 4.0.0
    webpack: ^5.53.0 => 5.53.0
    webpack-bundle-tracker: ^1.3.0 => 1.3.0
    webpack-cli: ^4.8.0 => 4.8.0

[alexander-akait]

file-loader is deprecated for v6, please migrate on asset modules https://webpack.js.org/guides/asset-modules/

[alexander-akait]

Or use type: 'javascript/auto'

[ThiefMaster]

So what's the solution for people who don't want to migrate yet? type: 'javascript/auto' doesn't seem to help; I'm still getting (broken) bundle-style urls instead of the urls file-loader generates.

[alexander-akait]

Keep using v5 if you don't want to migrate or set esModule: false to use require

[AdamHess]

@amlbar in the latest version they (I don't know why) made images automatically be substituted with a hash value for the file name.

You can turn this off by setting url: false I really want to know the design decision behind this. it should be one of those things that are explicitly configured, as this is a major deviation from older versions of css-loader.

[alexander-akait]

Do you have file-loader?

[AdamHess]

@alexander-akait its got nothing to do with file loader (though it is a possibility) css-loader need to be explicitly told to not use hashing for the file names.

[alexander-akait]

css-loader doesn't use hashes, file-loader is deprecated and you can have problems with hashes if you use it

[AdamHess]

I see the error of my ways (I reread the docs) seems as though I solved my problem accidentally by preventing it from touching urls. (I was working on a bulk migration from webpack 4 to 5. Way too many deps to figure out what needed to removed/changed due to deprecation)

…

On Thu, Apr 7, 2022, 8:42 PM Alexander Akait ***@***.***> wrote: css-loader doesn't use hashes, file-loader is deprecated and you can have problems with hashes if you use it — Reply to this email directly, view it on GitHub <#1380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLOEBTHVHQE3E6SSVBD6SLVD56HJANCNFSM5EKMK5VQ> . You are receiving this because you commented.Message ID: ***@***.***>

[Chinmay2709]

I am using asset module, and still have the same issue, how would I resolve this, I have latest Css-loader, web-pack and I am also using asset/modules still facing the same issue.

[CaliThemanDC]

So what is the fix to get the reference object that is generated to reference the generated sprite.svg file.

Instead of the export default { id: '', viewBox: '', url: '', toString: ''}