Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong URL for background images #1380

Closed
amlbar opened this issue Sep 19, 2021 · 9 comments
Closed

Wrong URL for background images #1380

amlbar opened this issue Sep 19, 2021 · 9 comments

Comments

@amlbar
Copy link

amlbar commented Sep 19, 2021

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
Copy link
Member

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

@alexander-akait
Copy link
Member

Or use type: 'javascript/auto'

@ThiefMaster
Copy link

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
Copy link
Member

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

@AdamHess
Copy link

AdamHess commented Apr 7, 2022

@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
Copy link
Member

Do you have file-loader?

@AdamHess
Copy link

AdamHess commented Apr 7, 2022

@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
Copy link
Member

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

@AdamHess
Copy link

AdamHess commented Apr 8, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants