Can I disable absolute url() rebase in CSS?

sage
,
1

When I have @font-face { url(../fonts/foo.woff) } in a SCSS file, it compiles to url(/wp-content/....
I would like to keep the path relative in dist/.
Couldn’t find the appropriate Postcss (?) option.

(For context: my staging environment is not in the domain’s root. Yes, I know that is probably a bad idea. And yes, I know I can change publicPath, even dependant on the env, but this creates another layer of… mess, that I’d rather not untangle – if it helps you, consider this a curious query about the (opaque-ish, IMO) configuration of Postcss : )

2

Unless you have a PostCSS plugin that specifically re-writes your URLs, I believe what’s happening is that the paths are re-written by webpack as it goes through the process of optimizing, copying, and stuffing your assets into a manifest. From what I recall, this is just part of how webpack works: It’ll look through all of your CSS, find the assets you’re linking to, optimize, move, and manifest-ize them, and then re-writes the links in your CSS as it dumps int out to a file.

3

thanks!
but, hence my (?) after postcss… at some point something injects/resolves the publicPath into url(), and i wonder if there is a way to tell postcss webpack not to do that?

4

What have you tried so far?

You might look into this line in Sage’s webpack.config.js:

{ loader: 'resolve-url', options: { sourceMap: config.enabled.sourceMaps } },

It looks like that’s probably calling this package: https://www.npmjs.com/package/resolve-url-loader …Which appears to re-write URLs.

Webpack handles all assets that pass through the build process, so looking for the loader rules that handle the file type of whatever you’re trying to mess with (.scss in this case) is usually a good starting point.

I’d also recommend reading through the webpack docs to get an idea of how webpack works (even if you aren’t writing your own webpack config from scratch). Just a general understanding of some of webpack’s concepts (i.e., it’s not a task runner like gulp) can be very helpful for diagnosing and solving problems you run into in the build process.

5

Well, I tried grepping package.json for suspects :slight_smile:

I feel like you are on the right track, but reading through resolve-url-loader and the reasoning behind it suggests that what I’m trying to do really is a bad idea. Or at least, not worth the trouble. Btw, removing the resolve-url loader (unexpectedly) had no effect on my url()s.

And thank you on the general webpack info, coming from gulp and grunt I can see my fallacy now.