Vite fails to resolve html-proxy in vitest browser mode

[maxpatiiuk]

Describe the bug

This is a Vite bug that affects Vitest.

vite:html-inline-proxy plugin is supposed to resolve requests for module scripts from index.html, but it fails to do so in some environments. The issue is that this plugin expects URL to include ?html-proxy, but in some cases the URL instead includes ?v=12535af4&html-proxy, causing regex to not match, and thus request fails to resolve correctly. See Explanation section below for more details.

Reproduction

https://github.com/maxpatiiuk/vite-html-proxy-bug

Steps to reproduce

1. Clone this repository

   git clone https://github.com/maxpatiiuk/vite-html-proxy-bug
   cd vite-html-proxy-bug

2. Install dependencies

   npm install

3. Run vitest browser mode

   npx vitest

   See the following error message in the terminal:

10:42:08 AM [vite] Pre-transform error: Failed to parse source for import analysis because the content contains invalid JS syntax. You may need to install appropriate plugins to handle the .js file format, or if it's an asset, add "**/*.js" to `assetsInclude` in your configuration.
10:42:08 AM [vite] Internal server error: Failed to parse source for import analysis because the content contains invalid JS syntax. You may need to install appropriate plugins to handle the .js file format, or if it's an asset, add "**/*.js" to `assetsInclude` in your configuration.
  Plugin: vite:import-analysis
  File: /Users/mak13180/site/esri/vite-html-proxy-bug/node_modules/@vitest/browser/dist/client/tester/tester.html?v=0aab3063&html-proxy&index=0.js:7:41
  5  |      <link rel="icon" href="{__VITEST_FAVICON__}" type="image/svg+xml">
  6  |      <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  7  |      <title>Vitest Browser Tester</title>
     |                                          ^
  8  |      <script type="module" crossorigin src="/__vitest_browser__/tester-B8eJg1-s.js"></script>
  9  |      <link rel="modulepreload" crossorigin href="/__vitest_browser__/utils-CaCTRFti.js">
      at TransformPluginContext._formatError (file:///Users/mak13180/site/esri/vite-html-proxy-bug/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:49255:41)
      at TransformPluginContext.error (file:///Users/mak13180/site/esri/vite-html-proxy-bug/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:49250:16)
      at TransformPluginContext.transform (file:///Users/mak13180/site/esri/vite-html-proxy-bug/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:63993:14)
      at async PluginContainer.transform (file:///Users/mak13180/site/esri/vite-html-proxy-bug/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:49096:18)
      at async loadAndTransform (file:///Users/mak13180/site/esri/vite-html-proxy-bug/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:51929:27)
      at async viteTransformMiddleware (file:///Users/mak13180/site/esri/vite-html-proxy-bug/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:61881:24)

Explanation

Starting with Vitest 2.1.5, Vitest browser mode calls transformIndexHtml.

If html contains module scripts, preTransformRequest will be called:

vite/packages/vite/src/node/server/middlewares/indexHtml.ts

Line 257 in 4f5845a

preTransformRequest(server!, modulePath, decodedBase)

The request URL may look like /Users/mak13180/site/esri/arcgis-dashboards/node_modules/@vitest/browser/dist/client/tester/tester.html?html-proxy&index=0.js

Later, ensureVersionQuery is called to add version hash to query string:

vite/packages/vite/src/node/plugins/resolve.ts

Line 277 in 4f5845a

return ensureVersionQuery(res, id, options, depsOptimizer)

The updated URL: /Users/mak13180/site/esri/arcgis-dashboards/node_modules/@vitest/browser/dist/client/tester/tester.html?v=12535af4&html-proxy&index=0.js

Such URL is supposed to be resolved by the vite:html-inline-proxy plugin:

vite/packages/vite/src/node/plugins/html.ts

Lines 96 to 106 in 4f5845a

	name: 'vite:html-inline-proxy',
	resolveId(id) {
	if (isHTMLProxy(id)) {
	return id
	}
	},
	load(id) {
	const proxyMatch = htmlProxyRE.exec(id)
	if (proxyMatch) {

, however, that does not work.

Here is the bug: the regex that checks for html-proxy URLs expects the URL to contain ?html-proxy, where as the above URL contains &html-proxy:

vite/packages/vite/src/node/plugins/html.ts

Lines 52 to 53 in 4f5845a

	const htmlProxyRE =
	/\?html-proxy=?(?:&inline-css)?(?:&style-attr)?&index=(\d+)\.(?:js|css)$/

.

Because of that, pluginContainer.load(id) fails to resolve the file. In such cases, it falls back to reading the file from the file system:

vite/packages/vite/src/node/server/transformRequest.ts

Line 276 in 4f5845a

code = await fsp.readFile(file, 'utf-8')

fs.readFile() ignores the query string, reads the tester.html file, and serves it - however, the .js file was expected. This causes an error in the Pre-transform during import analysis.

Solution

Vite should update the following regexes:

vite/packages/vite/src/node/plugins/html.ts

Lines 52 to 54 in 4f5845a

	const htmlProxyRE =
	/\?html-proxy=?(?:&inline-css)?(?:&style-attr)?&index=(\d+)\.(?:js|css)$/
	const isHtmlProxyRE = /\?html-proxy\b/

Should replace \? by [?&].

For reference, this is already correct in the vite:css-post plugin:

vite/packages/vite/src/node/plugins/css.ts

Line 227 in 4f5845a

const htmlProxyRE = /[?&]html-proxy\b/

.

Also, the Vite team should evaluate whether this bug affects any other Vite plugins.

System Info

System:
    OS: macOS 15.2
    CPU: (10) arm64 Apple M1 Pro
    Memory: 702.52 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.12.0 - ~/.local/state/fnm_multishells/98022_1737052578656/bin/node
    Yarn: 1.22.19 - ~/.local/state/fnm_multishells/98022_1737052578656/bin/yarn
    npm: 10.9.0 - ~/.local/state/fnm_multishells/98022_1737052578656/bin/npm
    pnpm: 8.9.0 - ~/.local/state/fnm_multishells/98022_1737052578656/bin/pnpm
  Browsers:
    Chrome: 131.0.6778.265
    Safari: 18.2
  npmPackages:
    vite: ^5.2.0 => 5.4.11 

Reproducible in `@vitest/browser` in 2.1.5 and above including 3.0.0 (related commit: https://github.com/vitest-dev/vitest/commit/169028f03abf5e80d77924f4ed9ae6107647c4c0). Not reproducible in 2.1.3 as transformIndexHtml wasn't called in that version.

Reproducible with Playwright and default provider in headless and headed mode in Chrome and Chromium. Reproducible with yarn monorepo and npm.

Used Package Manager

npm

Logs

Click to expand!

Too large for github. File log.log

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[hi-ogawa]

Thanks for the repro and investigation👍 Can you also explain which plugins actually have this issue (namely injecting inline module script)? If there's a common plugin employing this pattern, it's good for us to know.

Also for your use case, is it possible to workaround it by disabling this plugin on Vitest browser mode (e.g. by !process.env.VITEST && yourPlugin())?

[maxpatiiuk]

Thanks for quick reply!

Can you also explain which plugins actually have this issue

I created a Vite plugin for usage within my company for authoring and building web component libraries. Unfortunately, the source code is not open source.

namely injecting inline module script

The plugin is injecting code like the following into index.html

[
  {
    tag: 'script',
    attrs: { type: 'module' },
    children: 'globalThis.litIssuedWarnings ??= new Set();\n' +
      'globalThis.litIssuedWarnings.add(\n' +
      '"Lit is in dev mode. Not recommended for production! See https://lit.dev/msg/dev-mode for more information.",\n' +
      ');'
  },
  {
    tag: 'script',
    attrs: { type: 'module' },
    // ?layered flag is handled by my plugin
    children: 'import styles$0 from "@esri/calcite-components/calcite/calcite.css?layered";\n' +
      'document.adoptedStyleSheets = [...document.adoptedStyleSheets, styles$0.styleSheet];\n' +
      'import { defineCustomElements as defineCustomElements$0 } from "@esri/calcite-components/loader";\n' +
      'defineCustomElements$0({\n' +
      '  resourcesUrl: "/@fs/Users/mak13180/site/esri/arcgis-web-components-3/node_modules/@esri/calcite-components/dist/calcite/",\n' +
      '});'
  },
  {
    tag: 'link',
    attrs: {
      rel: 'stylesheet',
      href: '/@fs/Users/mak13180/site/esri/arcgis-web-components-3/node_modules/@arcgis/core/assets/esri/themes/light/main.css',
      id: 'arcgisCoreStylesheet'
    }
  },
  {
    tag: 'script',
    attrs: { type: 'module' },
    children: 'import { defineCustomElements } from "/Users/mak13180/site/esri/arcgis-web-components-3/packages/map-packages/map-components/src/loader.ts";\n' +
      'window.devOnly$ownTagNames = new Set();\n' +
      'defineCustomElements();'
  }
]

This code loads css for our dependencies, as well as setups lazy loading of web components.

It is needed in regular dev sever, storybook dev server and vitest dev server

is it possible to workaround it by disabling this plugin on Vitest browser mode

Ah, absolutely! Before Vitest browser mode started calling transformIndexHtml, I was using test setup files for this.
Now that I realized that this bug got triggered by transformIndexHtml being run, I can ignore the transformIndexHtml hook when running in vitest browser mode and keep using setup files.

Can confirm this works around the issue in Vitest ^2.1.5
side note: reminded me of https://xkcd.com/1172/