deno-vite-plugin

Pins to at workflow scope. Both jobs (, ) only check out, install deno + node, and run / and . No GitHub API write. Defense-in-depth motivation is CVE-2025-30066 on : a compromised third-party action runs inside the existing job context and exfiltrates the workflow via build logs. and are third-party here, so the cap is meaningful. Style matches the per-job block in . YAML validated locally with .

A monorepo where a workspace member (, , …) is imported by a Vite app fails to resolve any import that relies on the member's own import map — an aliased import (e.g. ) or a dependency declared in that member's . Vite reports for the alias case and for the jsr case, even though the same imports work under plain Deno. The cause is in . When a Deno module re-exports a local file, the plugin returns that file to Vite as a plain path, dropping its Deno context. Vite then processes the file and resolves its imports with a plain-path importer, so the plugin fell to the referrer-less path: A workspace member's are scoped to that member's directory, so without a referrer the loader only consults the root import map — where the alias / member-local jsr dependency does not exist. Both reported failures are this one root cause. The fix resolves bare/aliased specifiers relative to the importing file (via ), so member-scoped maps are honored. It runs before the heuristic and on the original specifier, so a member-scoped entry wins over the root map on a name collision. Guards keep the blast radius tight: relative and absolute specifiers are still left to Vite's resolver; importers under and Vite's virtual/URL-ish ids (, , ) are excluded, so dependency resolution and Vite internals are untouched; the existing Deno-specifier importer path is byte-for-byte unchanged; a referrer miss falls through to the previous behavior. Tests The fixture gains a member-scoped alias () and a jsr import (), neither present in the root map. The linked module is now executed at runtime (a new test case calls and asserts its value), so the member-scoped imports are validated at runtime, not just at build. With the fix reverted the fixture build fails with the same error; with the fix all tests pass. Verified end-to-end against a real reproduction repo: the app builds with the patched plugin and fails with the released one. Not covered (follow-up) npm dependencies declared in a member's import map are a separate, deeper issue and are intentionally left out of scope. An npm specifier resolved from a linked/member package returns , so the plugin hands it back to Vite, whose node resolution then looks from the member's directory rather than the app's and fails. Fixing that requires resolving the npm specifier to disk inside the main plugin (as already does for -prefixed ids), which is best done in its own change.

Hi, I’m opening this issue to report a build failure when using with a worker that imports a package from JSR. Reproduction I created a minimal reproduction here: https://github.com/etienne-sandbox/vite-deno-worker-repro The relevant setup is: main.ts creates a module worker with worker.ts imports a JSR package: Steps to reproduce 1. Clone the repro repository 2. Run: Expected behavior The production build should succeed, and the worker should be bundled correctly. Actual behavior The build fails during the Vite/Rolldown step with an unresolved import error for the JSR package. Example error: Additional notes This appears to be specific to JSR packages imported from worker code. For comparison, importing the same package from npm works fine: I’m not sure whether this is expected behavior or a bug in the plugin’s worker resolution path, but the repro suggests that does not correctly handle this case during production builds. Thanks!