[PR #119] [CLOSED] fix(deploy): detect bun.lock text format and walk up to monorepo root #326

New issue

Closed

opened 2026-05-06 12:39:13 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:39:13 +02:00

Owner

📋 Pull Request Information

Original PR: https://github.com/cloudflare/vinext/pull/119
Author: @harrisrobin
Created: 2/26/2026
Status: ❌ Closed

Base: main ← Head: fix/bun-lock-detection

📝 Commits (2)

dd656fe chore: add .worktrees/ to .gitignore
3d1203d fix(deploy): detect bun.lock text format and walk up to monorepo root

📊 Changes

3 files changed (+104 additions, -8 deletions)

View changed files

📝 .gitignore (+3 -0)
📝 packages/vinext/src/utils/project.ts (+42 -8)
📝 tests/deploy.test.ts (+59 -0)

📄 Description

Problem

detectPackageManager (and detectPackageManagerName) in utils/project.ts had two bugs that combined to make vinext deploy fail in Bun monorepos:

Wrong lockfile name. The function only checked for bun.lockb — the legacy binary format. Bun v1.0+ writes a text-based bun.lock file. Projects using Bun ≥ v1.0 were not detected as Bun workspaces.
No upward directory traversal. In a monorepo the lock file lives at the workspace root, not inside each app directory. When called from e.g. apps/web/, the function only checked that directory — missed the root — and fell through to npm install -D.

Both issues together produced this confusing error at the end of the npm fallback:

npm error Invalid Version:
Error: Command failed: npm install -D @cloudflare/vite-plugin@latest wrangler@latest @vitejs/plugin-rsc@latest
    at installDeps (dist/deploy.js:534:5)

Fix

Add bun.lock check alongside the existing bun.lockb check.
Walk up parent directories (stopping at the filesystem root) until a lock file is found, mirroring how npm/pnpm/yarn resolve workspace roots.
Both changes applied to detectPackageManager (returns install command) and detectPackageManagerName (returns pm name).

The helper is refactored into two small functions: checkLockFiles (single-directory check) and findLockFile (the upward walk), keeping each unit testable in isolation.

Tests

7 new unit tests in tests/deploy.test.ts:

pnpm detection via pnpm-lock.yaml
yarn detection via yarn.lock
bun detection via bun.lock (text, new)
bun detection via bun.lockb (binary, legacy)
npm fallback when no lock file found
monorepo root traversal (apps/web/ → lock file at workspace root)
closest-lock-wins precedence (inner pnpm-lock.yaml beats outer bun.lock)

✓ detects pnpm from pnpm-lock.yaml
✓ detects yarn from yarn.lock
✓ detects bun from bun.lock (text format, Bun v1.0+)
✓ detects bun from bun.lockb (legacy binary format)
✓ falls back to npm when no lock file is found
✓ walks up to parent directory to find lock file (monorepo root)
✓ prefers the closest lock file when both child and parent have one

pnpm run lint and pnpm run typecheck pass clean.

/bonk

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/cloudflare/vinext/pull/119 **Author:** [@harrisrobin](https://github.com/harrisrobin) **Created:** 2/26/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/bun-lock-detection` --- ### 📝 Commits (2) - [`dd656fe`](https://github.com/cloudflare/vinext/commit/dd656fee5b07e59eb887614a43dd9069fae227f3) chore: add .worktrees/ to .gitignore - [`3d1203d`](https://github.com/cloudflare/vinext/commit/3d1203d3e0ea22180f3d81f3964368da7567bdf3) fix(deploy): detect bun.lock text format and walk up to monorepo root ### 📊 Changes **3 files changed** (+104 additions, -8 deletions) <details> <summary>View changed files</summary> 📝 `.gitignore` (+3 -0) 📝 `packages/vinext/src/utils/project.ts` (+42 -8) 📝 `tests/deploy.test.ts` (+59 -0) </details> ### 📄 Description ## Problem `detectPackageManager` (and `detectPackageManagerName`) in `utils/project.ts` had two bugs that combined to make `vinext deploy` fail in Bun monorepos: 1. **Wrong lockfile name.** The function only checked for `bun.lockb` — the legacy binary format. Bun v1.0+ writes a text-based `bun.lock` file. Projects using Bun ≥ v1.0 were not detected as Bun workspaces. 2. **No upward directory traversal.** In a monorepo the lock file lives at the workspace root, not inside each app directory. When called from e.g. `apps/web/`, the function only checked that directory — missed the root — and fell through to `npm install -D`. Both issues together produced this confusing error at the end of the npm fallback: ``` npm error Invalid Version: Error: Command failed: npm install -D @cloudflare/vite-plugin@latest wrangler@latest @vitejs/plugin-rsc@latest at installDeps (dist/deploy.js:534:5) ``` ## Fix - Add `bun.lock` check alongside the existing `bun.lockb` check. - Walk up parent directories (stopping at the filesystem root) until a lock file is found, mirroring how npm/pnpm/yarn resolve workspace roots. - Both changes applied to `detectPackageManager` (returns install command) and `detectPackageManagerName` (returns pm name). The helper is refactored into two small functions: `checkLockFiles` (single-directory check) and `findLockFile` (the upward walk), keeping each unit testable in isolation. ## Tests 7 new unit tests in `tests/deploy.test.ts`: - pnpm detection via `pnpm-lock.yaml` - yarn detection via `yarn.lock` - bun detection via `bun.lock` (text, new) - bun detection via `bun.lockb` (binary, legacy) - npm fallback when no lock file found - monorepo root traversal (`apps/web/` → lock file at workspace root) - closest-lock-wins precedence (inner `pnpm-lock.yaml` beats outer `bun.lock`) ``` ✓ detects pnpm from pnpm-lock.yaml ✓ detects yarn from yarn.lock ✓ detects bun from bun.lock (text format, Bun v1.0+) ✓ detects bun from bun.lockb (legacy binary format) ✓ falls back to npm when no lock file is found ✓ walks up to parent directory to find lock file (monorepo root) ✓ prefers the closest lock file when both child and parent have one ``` `pnpm run lint` and `pnpm run typecheck` pass clean. /bonk --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>