[WIP] Deno as a package manager

[SisyphusZheng]

RFC: Deno as a Vite+ Package Manager

Summary

Add deno to Vite+ as a first-class package manager alongside npm, pnpm,
yarn, and bun. When Vite+ detects a Deno project, vp install should invoke
deno install and subsequent vp commands should respect Deno's
deno.lock / deno.json workspace model.

Motivation

Deno 2 fully supports package.json, node_modules, and npm dependencies. For
Deno-native projects, the only missing piece of a unified toolchain is a
single-command entry point. Vite+ already provides that for Node/npm projects;
extending it to Deno would make Vite+ a true "Unified Toolchain for the Web"
rather than a Node-only toolchain.

openElement is a Deno-origin Web Components full-stack framework that already
uses Vite and Nitro. It is an ideal dogfood: ESM-first, Web Standards-first,
multi-package workspace, with no desire to migrate to Node/npm. Having Vite+
recognize Deno would let such projects keep their runtime and package manager
while gaining a unified dev/build/check/test/pack entry point.

Scope

Package-manager detection

Detect Deno when any of the following are present (in descending priority):

1. packageManager: "deno@x.y.z" in package.json
2. devEngines.packageManager.name === "deno" in package.json
3. deno.json / deno.jsonc at the workspace root
4. deno.lock at the workspace root
5. deno binary available on PATH (fallback)

vp install

When Deno is detected, invoke:

deno install

Pass through extra args (--frozen, --allow-scripts, etc.) where semantically
compatible.

Enum / selector updates

Add deno to the internal PackageManager enum and the interactive
selectPackageManager picker.

Guards for Deno-specific behavior

Deno does not use:

• .yarnrc.yml / yarn resolutions
• pnpm-workspace.yaml / pnpm overrides / pnpm catalogs
• .bunfig.toml / bun untrusted builds
• package-lock.json

Vite+ should skip these code paths for Deno instead of falling through to an
npm/pnpm/yarn/bun branch.

Non-Goals

• Not making Deno a Vite+ managed runtime (vp env installing Deno). Deno
  is used as a system package manager, like npm/pnpm/yarn/bun already are.
• Not replacing deno.json with package.json workspaces. Deno's
  deno.json workspace convention should remain valid.
• Not full command parity in the first iteration. vp add/remove/update can
  be deferred; vp install is the MVP.
• Not altering Vite's bundling/runtime behavior. Vite itself still runs on
  Node; this proposal is about package-manager dispatch.

Case Study: openElement

openElement is a Web Components full-stack framework built on Deno. It has:

• 11 packages in a deno.json workspace
• deno.lock as the lockfile
• npm dependencies via npm: specifiers
• Vite and Nitro already in use

Current behavior when running vp install on openElement:

• Vite+ does not recognize deno.json / deno.lock.
• It falls back to pnpm and creates pnpm-lock.yaml.
• This is wrong for a Deno-first project.

Expected behavior:

• Vite+ detects Deno.
• vp install runs deno install.
• deno.lock remains the source of truth.

Repository: https://github.com/open-element/openelement

Implementation Notes

Audit of vite-plus@0.2.1 suggests:

• Package-manager detection is exported from the Rust binding as
  detectWorkspace, returning packageManagerName.
• vp install command dispatch is handled by the Rust run/runCommand
  binding.
• The JS bundle hardcodes PackageManager = { pnpm, npm, yarn, bun } and
  pattern-matches it in many places.

Therefore the change is split across:

1. Rust core: extend detectWorkspace with Deno signals; map vp install
   to deno install.
2. JS bundle: add deno to the enum/selector; add guards in
   rewriting/bootstrap logic so Deno is not mis-handled.

Suggested Detection Order Update

Update docs/guide/install.md to list Deno signals after bun.lock/bun.lockb
and before the fallback:

1. packageManager in package.json
2. devEngines.packageManager in package.json
3. pnpm-workspace.yaml
4. pnpm-lock.yaml
5. yarn.lock or .yarnrc.yml
6. package-lock.json
7. bun.lock or bun.lockb
8. deno.json / deno.jsonc / deno.lock   <-- new
9. .pnpmfile.cjs or pnpmfile.cjs
10. bunfig.toml
11. yarn.config.cjs

Open Questions

1. Should Vite+ write devEngines.packageManager when bootstrapping a Deno
   project, or should it prefer recording the package manager in deno.json?
2. How should Vite+ handle Deno workspaces (deno.json workspace array)?
3. Should vp install on Deno pass --frozen by default to match pnpm/yarn
   behavior, or rely on Deno's own defaults?
4. What is the recommended way to test Deno detection without shipping a Deno
   binary in CI?

Related

• Deno 2 package.json and node_modules support:
  https://docs.deno.com/runtime/fundamentals/configuration/
• Vite+ package manager docs: https://viteplus.dev/guide/install
• openElement dogfood observations: (to be linked after publication)

[netlify]

✅ Deploy Preview for viteplus-preview canceled.

Name	Link
🔨 Latest commit	929ec2c
🔍 Latest deploy log	https://app.netlify.com/projects/viteplus-preview/deploys/6a35160bcc214900085d666a

[fengmk2]

For the same reasons as #1379 (comment), we currently have no plans.

[SisyphusZheng]

thx for reply