Is there a way to prevent vite from transforming CSS files?

[CGNonofr]

TL;DR: When using the new URL('./myfile.css', import.meta.url), is there a way to prevent vite from trying to resolve url(...) in the css file?

My use-case

Via monaco-vscode-api, VSCode webview are registered by extension, whose assets files are registered via the new URL('./myfile.css', import.meta.url) syntax.

Some VSCode extensions are injecting css files in the webviews, and that css NEEDS to be kept as-is, because a service-worker is used to retrieve the actual assets, and it fails if the path is rewritten.

Actual css:

@font-face {
	font-family: "myfontfamilly";
	src: url("./myfontfamilly.ttf") format("truetype");
}

Css after vite transformation:

@font-face {
	font-family: "myfontfamilly";
	src: url("/node_modules/myExtensionPackage/myfontfamilly.ttf") format("truetype");
}

For some reasons, it seems to be happening only in serve mode

It can be a vite configuration or a query parameter (line inline, raw, worker...), I've tried them all, and nothing helps (except commonjs-proxy for some reasons, but it would be VERY hacky)

[DucMinhNe]

The url() rewriting happens because, even with new URL('./x.css', import.meta.url), the file still ends up being served through Vite's CSS pipeline in dev. That pipeline's transform hook only excludes requests matching SPECIAL_QUERY_RE (/[?&](?:worker|sharedworker|raw|url)\b/), and otherwise matches purely on the CSS extension — so an ordinary CSS request always gets its url() references resolved/rewritten (css.ts, constants.ts).

A couple of ways to get the file verbatim:

1. Use a ?raw import (not new URL) to skip the CSS transform entirely

raw is in SPECIAL_QUERY_RE, so the CSS transform hook is bypassed; the asset plugin's load handler just reads the file from disk (fs.readFile) and returns it as a string — no url() rewriting:

import cssText from './myfile.css?raw'

// build a URL the service worker can fetch:
const url = URL.createObjectURL(new Blob([cssText], { type: 'text/css' }))

This keeps url("./myfontfamilly.ttf") exactly as authored. Note this is a static import, not new URL('./myfile.css?raw', import.meta.url) — the new URL(..., import.meta.url) form resolves to an asset URL that, for CSS in dev, is still served through the CSS endpoint, which is why ?raw via new URL didn't help you. The trade-off with the blob approach is that it's a blob URL rather than the original on-disk path, so the service worker's relative resolution has to account for that.

2. Serve it from public/ for a verbatim, path-stable URL

Files under public/ are served at / during dev (and copied to dist as-is), and never enter the CSS pipeline. Reference by its root-absolute URL:

const url = '/myfile.css'

The file (and its sibling .ttf) are served untouched, so a relative url("./myfontfamilly.ttf") resolves to /myfontfamilly.ttf — correct as long as the .ttf sits next to the CSS at the same public path. Since your assets live inside an npm package, you'd copy them into public/ via a small build step or vite-plugin-static-copy.

Why ?url/?inline didn't help

?url is in SPECIAL_QUERY_RE, but for *.css?url in dev the CSS load hook explicitly defers to the assets plugin (there's a literal // in dev, it's handled by assets plugin comment), and the asset URL it produces still points at the CSS dev endpoint — so the rewrite still happens. ?inline returns the compiled CSS string, which is also post-transform. ?raw is the one query that returns the file bytes before any CSS processing.

Of the two, ?raw + blob (option 1) is usually the most self-contained when the assets come from node_modules rather than your own source tree.

[CGNonofr]

Another approach that would works for me is to play with the Accept header: I can't set any value. Currently, any Accept header would return an ES module, except the text/css that return the transformed css. Would it be acceptable that a application/octet-stream or a text/plain return the content unchanged?

[CGNonofr]

I'm still confused on why the file is not transformed in build mode though, or is it?

[DucMinhNe]

It's not transformed in build because it goes through a different path: with
new URL(..., import.meta.url) the .css is treated as a plain static asset and
just copied to dist as-is, so the inner url("./myfont.ttf") is left alone.

In dev there's no asset-copy step — the same URL gets served as a normal .css
request, which hits the CSS transform hook and rewrites url(). So it's not
that build "keeps CSS untouched" on purpose; the two modes just take different
routes and happen to disagree.

That's also why this feels like a bug to me too. Rather than adding a new
?direct-raw query (still Vite-specific, same portability issue as ?raw), I
think the cleaner fix is: new URL('./x.css', import.meta.url) should give you
the same untouched asset in dev that it already does in build. Just make the
two consistent.

The Accept-header idea is nice because it needs no query string, but a service
worker fetch can't always set Accept, and Vite has no content negotiation
today — so that's a bigger feature, probably a maintainer call.

[CGNonofr]

I think I've find a simple solution not involving headers or query params, will open a PR 🤔

[CGNonofr]

What do you think of #22650 ?