Failed to resolve import ignores optimizeDeps.exclude

[tarngerine]

Describe the bug

I am writing a app that will be loaded in an environment that has a module available already (specifically Chrome's WebUI, which has modules at chrome://resources/js/cr.m.js)

So I have marked in a vite.config.ts that optimizeDeps.exclude = ['chrome://resources/js/cr.m.js'] as well as build.rollupOptions.external = ['chrome://resources/js/cr.m.js']

Build works fine, but dev mode complains that the import fails to resolve. I'd expect optimizeDeps.exclude to tell vite to ignore trying to load this module itself.

Reproduction

https://stackblitz.com/edit/vitejs-vite-p5rvav?file=src/main.ts,vite.config.ts,src/test.ts&terminal=dev

System Info

stackblitz based on vanilla-ts example, see repro link https://stackblitz.com/edit/vitejs-vite-p5rvav

Used Package Manager

npm

Logs

[plugin:vite:import-analysis] Failed to resolve import "chrome://resources/js/cr.m.js" from "src/main.ts". Does the file exist?
/home/projects/vitejs-vite-p5rvav/src/main.ts:2:0
1  |  import * as prod from "chrome://resources/js/cr.m.js";
   |                         ^
2  |  import * as dev from "./test";
3  |  export const api = import.meta.env.prod ? prod : dev;
    at formatError (/home/projects/vitejs-vite-p5rvav/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:38663:46)
    at TransformContext.error (/home/projects/vitejs-vite-p5rvav/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:38659:19)
    at normalizeUrl (/home/projects/vitejs-vite-p5rvav/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:56830:26)
    at async TransformContext.transform (/home/projects/vitejs-vite-p5rvav/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:56979:57)
    at async Object.transform (/home/projects/vitejs-vite-p5rvav/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:38900:30)
    at async doTransform (/home/projects/vitejs-vite-p5rvav/node_modules/vite/dist/node/chunks/dep-59dc6e00.js:55857:29

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 https://github.com/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.

[tarngerine]

I have found a workaround which is a bit nonsensical, but at least I am unblocked — this would be nice to fix, though!

Things I have tried:

Using dynamic import with vite-ignore (await import(/* @vite-ignore */))

This has the same error, vite still tries to resolve the module even though there's a /* @vite-ignore */ in it

even if it's conditionally after an import.meta.env.PROD flag vite will try to resolve it

// errors
const prodAPI = import.meta.env.PROD ? await import ('chrome://resources/js/cr.m.js') : null

// errors
const API = await import(import.meta.env.PROD ? 'chrome://resources/js/cr.m.js' : './test') 

Using regex/glob in optimizeDeps.exclude

Unfortunately this does not help, and continues to have the same error, using: chrome://* chrome:\/\/.* chrome://** (last one has a esbuild error because there cannot be two * in wildcard in esbuild

Using .env variable for the acutal import with a dynamic import

This works, but is feels hacky:

// .webui.ts
import * as WebUI from "chrome://resources/js/cr.m.js"; // Vite does not complain about this because we only use it for the type definition, so it is "compiled out" during typescript transpilation?

const prodAPI: typeof WebUI = import.meta.env.PROD
  ? await import(import.meta.env.VITE_WEBUI_MODULE) // This is properly ignored in dev environment
  : null;

// .env
VITE_WEBUI_MODULE=chrome://resources/js/cr.m.js

//vite.config.ts
build: {
  target: "esnext", // to support top level await for import
}

i can prob clean it up a bit but at least i am unblocked — in dev it properly ignores this module bc the env var is not loaded in at all, and in prod it builds properly after setting build target to esnext.

[bluwy]

Looks like this is externalizing a dep in dev, which isn't supported yet but being tracked at #6582. Similar to the linked issue, current Vite reports an error in vite:import-analysis