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("/p/https://github.com/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]

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 ?

[CGNonofr]

Is it a joke? Is github now a karma-farming platform only?

[DucMinhNe]

There's no per-file "don't touch this CSS" flag on the new URL(...) path, but there are two reliable ways to ship a CSS file byte-for-byte:

1. If you control the file: put it in public/. Everything under the public directory is copied verbatim — no url() rewriting, no hashing, stable paths. Reference it by absolute path (or via the service worker exactly as today). This is Vite's designed escape hatch for "must be kept as-is" assets, and it's the cleanest fix when the CSS (and the font next to it) can live there:

public/
  webview/
    myfile.css          <-- served/copied untouched
    myfontfamilly.ttf

2. If the new URL('./myfile.css', import.meta.url) lives in a dependency (your monaco-vscode-api case) and you can't move the file, you can short-circuit Vite's CSS asset pipeline with a tiny plugin that emits the file as a raw asset and resolves the import to that emitted file:

import { readFileSync } from 'node:fs';
import type { Plugin } from 'vite';

const KEEP_RAW = /[\\/]monaco-vscode-api[\\/].*\.css$/;

export function keepCssRaw(): Plugin {
  return {
    name: 'keep-css-raw',
    enforce: 'pre',
    async resolveId(id, importer) {
      const r = await this.resolve(id, importer, { skipSelf: true });
      if (r && KEEP_RAW.test(r.id)) {
        // ?url makes Vite treat it as a plain asset URL…
        return r.id + '?raw-asset';
      }
    },
    load(id) {
      if (id.endsWith('?raw-asset')) {
        const file = id.replace('?raw-asset', '');
        const ref = this.emitFile({
          type: 'asset',
          name: file.split(/[\\/]/).pop(),
          source: readFileSync(file), // byte-for-byte, url() untouched
        });
        return `export default import.meta.ROLLUP_FILE_URL_${ref};`;
      }
    },
  };
}

enforce: 'pre' matters — it has to win before vite:css claims the file. The emitted asset is the original buffer, so url("./myfontfamilly.ttf") survives. Caveat: the relative font next to it won't be auto-copied, so either emit the sibling files the same way or keep the whole webview asset folder together (which is why option 1 is preferable whenever you can use it).

One thing that does not work, to save you the experiment: build.assetsInlineLimit, assetsInclude, and css.transformer options don't opt a CSS file out of url() rebasing — that rewriting happens in Vite's CSS plugin for anything that flows through the module graph as CSS.

[CGNonofr]

Won't this plugin make the asset replaced by a ES module that default export the file url? It probably won't help

[DucMinhNe]

You're right, and I owe you a correction — I verified it against 8.0.16 and the plugin doesn't help here.

The reason is that new URL('./x.css', import.meta.url) never goes through the normal resolveId/load graph. assetImportMetaUrlPlugin resolves the specifier itself (its own tryFsResolve + fileToUrl) and rewrites the call in place. So my plugin's resolveId/load simply never see that .css — the dep transform is byte-for-byte identical with or without the plugin:

// dep/index.js, transformed (with AND without keepCssRaw):
export const cssUrl = new URL("/dep/x.css", '' + import.meta.url).href

The emitted-file / export default <url> shape would only fit a static import x from './x.css', which isn't what's happening. And the rewritten /dep/x.css URL still gets served through the CSS pipeline in dev, so the inner url("./myfont.ttf") is still rewritten to url("/p/https://github.com/dep/myfont.ttf"). So your read is correct on both counts — scratch that suggestion.

What actually holds up:

• public/ stays the robust, bundler-agnostic escape hatch — it's a verbatim copy, not a transform, so the inner url(...) is untouched. But that doesn't help when the file ships inside a dependency you don't control, which is exactly your monaco-vscode-api case.
• The real structural fix is making dev match build for new URL(..., import.meta.url) CSS — which is the direction of your fix: make asset handling consistent between serve and build (fix #22646) #22650. The asymmetry (build copies the asset as-is, dev re-routes it through the CSS transform) is the actual bug, and /@fs-raw/ addresses it at the source rather than papering over it with a query/header. I think that's the right shape; I'll take a closer look at the PR.

[fournarin]

[CGNonofr]

Thanks for your suggestion. But as said, I want to keep the new URL('...', import.meta.url) syntax as it's more modern, future-proof and not vite-specific

Also I don't want the content of the css file, I want an URL. It would required generating blob urls for it, which doesn't work for me (because the url are given to a cross-origin iframe). Also, it would inline all css file content in the code instead of lazy-loading it.

[JosephHampton]

The url(...) rewriting is happening because Vite treats .css as a first class module and runs its whole CSS pipeline (PostCSS plus asset URL resolution) over it. To get the file served exactly as is, you need to take it off that pipeline. A few ways depending on what you need:

1. ?raw gives you the literal file text, untouched:

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

No PostCSS, no url() rewriting, you just get the exact bytes as a string and can inject them yourself.

2. ?url gives you the URL without sending it through the CSS module pipeline:

import cssUrl from './myfile.css?url'

Vite treats it as an asset reference and copies it as is rather than processing the CSS.

3. Drop the file in public/. Anything in public/ is served and copied byte for byte with zero transformation, and you reference it by absolute path (/myfile.css). Since you've already got a service worker resolving the real assets, this is usually the cleanest fit for webview files.

For your VSCode webview case where the service worker needs the original url(...) paths intact, I'd go with public/ or ?raw, both keep the CSS byte identical. Since you're already using new URL('./myfile.css', import.meta.url), moving those assets into public/ and pointing the URL at the absolute path is probably the least friction fix.

Hope that helps. If it solves it, feel free to select it as the answer.

[CGNonofr]

What do you think of #22650

1. ?raw gives you the literal file text, untouched:

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

No PostCSS, no url() rewriting, you just get the exact bytes as a string and can inject them yourself.

2. ?url gives you the URL without sending it through the CSS module pipeline:

import cssUrl from './myfile.css?url'

Vite treats it as an asset reference and copies it as is rather than processing the CSS.

Ok, but I need the new URL(..., import.meta.url) to work as it's the standard way and not vite-specific

3. Drop the file in public/. Anything in public/ is served and copied byte for byte with zero transformation, and you reference it by absolute path (/myfile.css). Since you've already got a service worker resolving the real assets, this is usually the cleanest fit for webview files.

For your VSCode webview case where the service worker needs the original url(...) paths intact, I'd go with public/ or ?raw, both keep the CSS byte identical. Since you're already using new URL('./myfile.css', import.meta.url), moving those assets into public/ and pointing the URL at the absolute path is probably the least friction fix.

You mean moving file from node_modules to public by hands with a script, and rewriting all the import paths? I'm not sure how to actually implement that.

It's a vite bug, all workarounds are every complex. I've open a PR with a fix as simple as possible

[KryptosAI]

Yes — set css.modules.preProcessorOptions or use ?raw and ?url query suffixes on your imports.

The cleanest approach for your Monaco/VSCode use case:

Option 1: ?raw import (recommended)

// Vite treats this as a string, no CSS processing
const cssText = await import('./myfile.css?raw');
// use cssText.default

Vite skips all CSS transformation when you use ?raw. It just returns the file contents as a string. This is what I'd do for webview assets that are already pre-built.

Option 2: ?url import

const cssUrl = new URL('./myfile.css?url', import.meta.url);
// gets the unresolved file URL, no `url()` rewriting

Unlike new URL(..., import.meta.url) (which triggers asset processing), ?url tells Vite to treat it as an external URL reference.

Option 3: Configure build.assetsInlineLimit to 0

If your CSS files are under whatever threshold you set, Vite inlines them, which also means url() gets resolved during inlining. Setting it to 0 forces everything to remain as external files:

build: {
  assetsInlineLimit: 0,
}

Option 4: resolve.preserveSymlinks and custom plugin

If you need the new URL(..., import.meta.url) pattern specifically (Monaco might), you can write a tiny plugin that intercepts CSS imports and marks them as external:

{
  name: 'skip-css-transform',
  load(id) {
    if (id.endsWith('.css')) return '';
  },
}

For the VSCode webview assets case specifically, ?raw is almost certainly what you want — no transformation, just the text.

[CGNonofr]

A fourth almost identical entirely AI-generated non-relevant answer doesn't help at all