v4 can't resolve absolute URLs

[brenc]

Creating a new bug report because #1136 was locked. Not trying to cause any problems. This is mainly for documentation for those of us who have been affected by this change, want to keep our deps up to date, but can't easily remove absolute URLs from our CSS right now. I found a really simple workaround for this:

{
  test: /\.css$/,
  use: [
  {
    loader: 'css-loader',
    options: {
      url: (url, resourcePath) => {
        // Mimics v3 handling of absolute URLs.
        if (url.startsWith('/')) {
          return false
        }

        return true
      }
    }
  }
]
},

This seems to work exactly as v3 did.

@syberon
@petertenhoor

[brenc]

Closing right away as this was just for documentation and because this appears to be expected behavior in v4.

[syberon]

Thanks! I already found this workaround a few days before. I use the same workaround but just little simplified the code:

            {
                test: /\.(css)$/,
                use: [
                    {
                        loader: 'css-loader',
                        options: {
                            url: url => !url.startsWith('/')
                        }
                    }
                ]
            },

[alexander-akait]

You can send a PR to docs, if you think it can help other, anyway may recommendation is rewrite url or use aliases for this

[oles]

Thank you for this, @brenc and @syberon

I tried to update a while ago when 4.0.0 was released, and I got errors when building. Tried to do some small tweaks to my config based on the release notes to no effect.

Did some more maintenance today, and saw this had gotten a few more releases. Perhaps it is working now.
Nope, still errors, on my fairly minimal and simple setup.

Checked out the issues: nope. Checked out the closed ones: yes!
There were people with the same issue as me.

The first hit had me stumbling with aliases.
The second was this one - and my project built as it did before with the workaround.

Upgrading from version 3.5.3 to 4.2.2 resulted in "added 2 packages from 2 contributors", my webpack config growing from a simple 'css-loader' to {loader: 'css-loader', options: {url: url => !url.startsWith('/')}}, and about an hour of time.

Not unreasonable, though a minor hassle.
It's not the first time I've done similar things for the other packages, such as file-loader and copy-webpack-plugin for example.

I'm just hoping that by illustrating this with my simple use case, it might not be so in the future.

Thank you for your great work and the time you put into this, @evilebottnawi.

[alexander-akait]

You should not ignore / urls, why do you use this in source code? Can you provide example? I feel you have invalid structure and need refactor your project

[alexander-akait]

It's not the first time I've done similar things for the other packages, such as file-loader and copy-webpack-plugin for example.

what kind?

[oles]

You should not ignore / urls, why do you use this in source code? Can you provide example? I feel you have invalid structure and need refactor your project

For a long, long time, I've included fonts and other static assets like this:

I put the font file into the public folder, as it is static, and already optimized - it should not be touched, only referenced.
public/fonts/gotham/Gotham-Book.woff

Then I have some country flags, same thing as above, so I put some in the folder as well.
public/flags/dk.svg
public/flags/se.svg

Now, to make the font available to my app, I also add the corresponding css file for it.
Since it is unoptimized and should be added to my main css bundle - I add it to a different folder, for cases like that:

assets/gotham.css

that contains

@font-face {
    font-family: 'Gotham';
    font-weight: 400;
    font-style: normal;
    src: url('/fonts/gotham/Gotham-Book.woff') format('woff');
}

...

and then I include it via @import "assets/gotham.css"; in my index.css.

For the country flags, I'd do <img :src="'/flags/' + locale.code + '.svg'" alt="" aria-hidden/>, for example

I think this is quite a common way to use fonts and other static assets on websites without webpack.

[alexander-akait]

@oles Why do not change this to relative URL? If you put it in publish you should use:

@font-face {
    font-family: 'Gotham';
    font-weight: 400;
    font-style: normal;
    src: url('/public/fonts/gotham/Gotham-Book.woff') format('woff');
}

Otherwise it is invalid server relative URL, try to open css file in browser

[oles]

It's not the first time I've done similar things for the other packages, such as file-loader and copy-webpack-plugin for example.

what kind?

For file-loader, from version 4.3.0 to 5.0.0, the config grew from
{test: /\.(png|jpg|gif|svg)$/, loader: 'file-loader'} to
{test: /\.(png|jpg|gif|svg)$/, loader: 'file-loader', options: {esModule: false}}
after trying to figure out why the build didn't work anymore.

I have still to read up on why that was needed. It most likely had good reasoning.
It still affected many people, and, without knowing about why, ES modules seem out of place for file-loader.

For copy-webpack-plugin, from version 5.1.1 to 6.0.0, the config grew from
new CopyPlugin(['./public/'])
to
new CopyPlugin({patterns: ['./public/']})

Really minor that one.
Still feel like it should support passing just a single string, as it seems the most common use case is just to copy a single folder

[alexander-akait]

{test: /.(png|jpg|gif|svg)$/, loader: 'file-loader', options: {esModule: false}}

yes need to rewrite code on import or use require('./image.png').default

new CopyPlugin({patterns: ['./public/']})

expected because plugins should accept only object as options

[oles]

Why do not change this to relative URL?
Otherwise it is invalid server relative URL, try to open css file in browser

That's a fair point.
I'm almost always developing with a server, so it's quite common for me to think that / is always the public folder.

It wouldn't work if I were to develop with plain html and css files opened in the browser.

I'll have to consider. Most people do start to develop with just plain files. Perhaps it's better to just keep it that way - simpler, and it works regardless a server or not.

[alexander-akait]

@oles

I'm almost always developing with a server, so it's quite common for me to think that / is always the public folder.

you need to use same public path for static server and in webpack config

[oles]

yes need to rewrite code on import or use require('./image.png').default

There we have it. Makes sense. I've been bitten by that before.
I just didn't connect it with the esModule name.

expected because plugins should accept only object as options

Didn't know that was the case. Makes sense when so 👍

[oles]

you need to use same public path for static server and in webpack config

I've always had it as publicPath: '/', as it made things work the way I was used to 😉
And now it lead to this - seems I have some homework to do!

Thanks for the replies and the inputs!

[alexander-akait]

I've always had it as publicPath: '/', as it made things work the way I was used to wink

As I written above you need to use in your case

@font-face {
    font-family: 'Gotham';
    font-weight: 400;
    font-style: normal;
    src: url('/public/fonts/gotham/Gotham-Book.woff') format('woff');
}

[oles]

As I written above you need to use in your case

Indeed, I'm gonna try it out next session - thanks!