Images in css files do not get assetsPrefix in production build

[marishkaSunrise]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

When add static background images to css files, Gatsby 5 doesn't add assetPrefix (added to gatsby-config.js) to them in production build. It makes it impossible to use cdn, because not all images can be added to js files as img HTML tag or imported to components where assetPrefix is being applied correctly (with withPrefix function).

Reproduction Link

https://codesandbox.io/s/wandering-rgb-hx2pp4

Steps to Reproduce

Create a css file
.container { background-image: url("/logo.svg") }

Add container class name to html

Add to gatsby-config.js:
assetPrefix: https://cdn.example.com

Build the app for production, see pages source code , inlined styles do not have assetsPrefix added to image paths.

Expected Result

In prod output inlined css styles should look like

<style>.container{backgrround-image:url('https://cdn.example.com/logo.svg')}</style>

Actual Result

<style>.container{backgrround-image:url('/logo.svg')}</style>

Environment

System:
    OS: macOS 13.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.12.1/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
  Browsers:
    Chrome: 109.0.5414.119
    Firefox: 108.0.2
    Safari: 16.2
  npmPackages:
    gatsby: ^5.6.0 => 5.6.0
    gatsby-link: ^5.6.0 => 5.6.0
    gatsby-page-utils: ^3.6.0 => 3.6.0
    gatsby-plugin-canonical-urls: ^5.6.0 => 5.6.0
    gatsby-plugin-env-variables: ^2.3.0 => 2.3.0
    gatsby-plugin-eslint: ^4.0.3 => 4.0.3
    gatsby-plugin-manifest: ^5.6.0 => 5.6.0
    gatsby-plugin-preconnect: ^1.4.0 => 1.4.0
    gatsby-plugin-purgecss: ^6.2.1 => 6.2.1
    gatsby-plugin-root-import: ^2.0.9 => 2.0.9
    gatsby-plugin-sass: ^6.4.0 => 6.6.0
    gatsby-plugin-sitemap: ^6.4.0 => 6.6.0
    gatsby-plugin-split-css: ^2.0.3 => 2.0.3
    gatsby-plugin-styled-components: ^6.4.0 => 6.6.0
    gatsby-source-filesystem: ^5.6.0 => 5.6.0
  npmGlobalPackages:
    gatsby-cli: 5.6.0

Config Flags

No response

[pieh]

Are you using --prefix-paths toggle when running gatsby build? See https://www.gatsbyjs.com/docs/how-to/previews-deploys-hosting/asset-prefix/#enable-prefixing-for-builds

I am getting prefix when I use this toggle. There was regression some time ago, but it was fixed in gatsby@5.4.0 ( #37429 )

[marishkaSunrise]

Yes, I do "gatsby build --prefix-paths" when build for prod. I get assets prefix for all css, js , images included directly to html files, but all background images added to css files directly are not getting assets prefix.

[pieh]

Ok, after some changes I manage to reproduce - this only happens when image / url path starts with /. When using correct relative path it works:

This seems to be because of this config

gatsby/packages/gatsby/src/utils/webpack-utils.ts

Lines 313 to 321 in 66584a2

	// Absolute urls (https or //) are not send to this function. Only resolvable paths absolute or relative ones.
	url: function (url: string): boolean {
	// When an url starts with /
	if (url.startsWith(`/`)) {
	return false
	}
	return true
	},

- I will try to check why it's done like that - there might be valid reason to use that

--edit:
So changes to when url starts with / were added in #29577 - generally they do make sense, however because those urls are skipped completely now so not only they don't receive hash (which we wouldn't want based on linked PR), but this also mean they won't receive prefixes. Will see if there's some configuration options to deal with it

[marishkaSunrise]

Thank you for checking! When I add static background images to css files with relative path starting with ../ ... in prod version I get assetsPath added, as well as caching name, thanks. But all svg images are inlined in css files as something like background-image:url(data:image/svg+xml;base64,.... I figured how to update webpack url loader's limit value to prevent inlining small files.

Sorry, this is not a bug, since everything works with a relative path.
I have a question which is related to images, not sure if I can post it here, since it's not a bug related.

All static images that are being added via js files as relative or absolute paths (not as an import) , for example, as <img src="../../static/images/logo.webp" />, or as <img src="/images/logo.webp" /> are added to public folder as public/images/logo.webp. This is expected based on this documentation https://www.gatsbyjs.com/docs/how-to/images-and-media/static-folder/. But static images that are added via css get copied into static folder to public folder, for example, original path is static/images/logo.webp, and in public folder the path turns into public/static/logo{caching-param}.webp.

The same static image is being treated differently if added via css or via js: different path in public folder, in one case it gets caching names, in other no. I kind of understand why it's happening but it leads to an issue when static files being added to public folder into multiple places. In my case the same static image static/images/logo.webp gets copied to public folder as public/static/logo{caching-param}.webp (if imported via css) and as public/images/logo.webp (by default since all static files are being copied to public). This logic duplicates the same image in public folder, and makes it to copy it to cdn twice. Not a really big problem, but we have about 10k images (more in the future) , and it might take some extra space on the server. We have all images optimized by our designers, so really no need to use Gatsby plugin image , so we have all images added to static folder. Do you know if there are any workarounds?

[marishkaSunrise]

Not a bug