Jeff See

[backends] Detect entrypoint after install and build commands (#17284) ### Description Stacked on #17283. The wrapper builders (`@vercel/express` et al.) resolve the entrypoint in `entrypointCallback`, which `@vercel/node` invokes **after** the install and build steps — so entrypoints generated by the build are found. The backends builder detected the entrypoint **before** running the Build Command, failing with "no entrypoint found" for the canonical tsc-style setup: ```json { "main": "dist/index.js", "scripts": { "build": "tsc" } } ``` This PR moves `maybeDoBuildCommand` ahead of entrypoint detection. Detection logic itself is unchanged; only the timing moves. ### Tests - New `test/unit.post-build-entrypoint.test.ts`: full `build()` against a fixture whose entrypoint only exists after the Build Command runs. Verified red/green — fails on the base commit, passes with this change. - `pnpm vitest-run --run test/unit.build.test.ts test/unit.find-entrypoint.test.ts` — 15 passed - `outputDirectory "."` symlink regression test in `unit.test.ts` — passed - `pnpm type-check` — clean

[CLI] Add opt-in config for native binary trampoline (#17209) ## Summary PR 1 of 2 for building native CLI binaries into the release flow. This PR adds the **opt-in gate** so the native `@vercel/vc-native-*` binary is never spawned unless the user explicitly opts in — a prerequisite before PR 2 wires `optionalDependencies` (which would otherwise make every install run the binary). ## Changes - **Config:** add flat `useNativeBinary` key to the global config (`@vercel/cli-config`). Adds a zod-free `@vercel/cli-config/paths` subpath so `vc.js` can read the flag on the startup hot path without loading zod/schemas (~40ms saved). - **Trampoline gate (`vc.js`):** only spawn the native binary when opted in — via the config flag or the `VERCEL_CLI_USE_NATIVE_BINARY` env override. Any failure to read config is treated as "not opted in", so we never spawn a binary the user didn't ask for. The `resolveNative()` check runs first and short-circuits, so there is no added cost when no native package is present. - **`vercel upgrade --binary [true|false]`:** toggles the opt-in, with telemetry. - **Auto-opt-in:** members of the `vercel` team are auto-opted-in, matched by the globally-unique team slug (no hardcoded team id), and only when the user has no explicit preference (an opt-out via `--binary false` is always respected). - **Tests:** trampoline gating (opt-in / opt-out) and the upgrade flag. ## Hot path note The opt-in read only runs when a native binary is actually resolvable. Today (no `optionalDependencies`) that's never, so the gate costs ~0ms. Once PR 2 lands, the zod-free `paths` read is ~7ms (dominated by `xdg-app-paths`); can be inlined further in PR 2 if a startup benchmark shows it matters. ## Follow-up PR 2: build binaries in the release flow, populate `optionalDependencies` before publishing `vercel`, and fail the publish if a binary build fails.

[cli] fix self-upgrade for pnpm 11 global installs and post-upgrade prompt (#16903) ### What Fixes three bugs in the CLI self-upgrade flow (`vc upgrade` and the post-command upgrade prompt): 1. **pnpm 11 global installs are misdetected as local npm installs.** The upgrade runs `npm i vercel@latest` in the user's **current working directory** — polluting whatever project (or home directory) they're standing in with a stray `node_modules`/`package.json` — and then reports success while the real installation is untouched. Reproduced on a **fully clean machine** (fresh fnm-installed Node, fresh standalone pnpm 11, single vercel install, latest CLI): ``` > [debug] Executing: npm i vercel@latest (cwd: /Users/jeffsee) > Success! Vercel CLI has been upgraded to v54.18.7 successfully! $ vc -v 54.17.3 # unchanged ``` 2. **Unrecognized install layouts default to executing a local install in the cwd.** This is the dangerous fallback underlying bug 1: any future layout change reintroduces the same failure. Running inside a pnpm/yarn workspace also fails loudly with `EUNSUPPORTEDPROTOCOL: Unsupported URL Type "workspace:"` because npm tries to resolve the surrounding workspace's dependency tree. 3. **The update prompt re-fires immediately after a successful `vc upgrade`.** The process still holds the pre-upgrade version in memory, so it asks "Would you like to upgrade now?" right after printing the upgrade success message. ### Why detection fails on pnpm 11 pnpm 11 moved global installs to isolated directories (`{PNPM_HOME}/global/v11/{hash}/`) backed by the global virtual store, so the install's realpath lives under `{storeDir}/links/...` ([pnpm 11 release notes](https://github.com/pnpm/pnpm/releases/tag/v11.0.0)). All three detection strategies in `get-update-command.ts` miss: - `pnpm root -g` answers with the *parent* of the isolated install dirs (not a `node_modules`), or — on machines upgraded from pnpm ≤10 — a stale `global/5` directory that pnpm does not migrate ([pnpm/pnpm#11528](https://github.com/pnpm/pnpm/issues/11528)), so `detectGlobalCliType` never matches - no lockfile exists above the install dir inside the store, so the lockfile scan falls through to `npm` - the store path does not contain `/pnpm/global/`, so the path heuristic misses, and the npm prefix check misses too → `global: false` Result: `{ cliType: 'npm', global: false }` → `npm i vercel@latest` in `process.cwd()`. ### How - **`isPnpmHomeInstall()`**: classify as pnpm + global when the unresolved entrypoint (`process.argv[1]`) or the realpath'd install dir is inside `PNPM_HOME`. This is layout-version independent — pnpm ≤10, 11, and future layouts all live under `PNPM_HOME` — and requires no shelling out. Checked before the existing query-based detection. - **Store-links path heuristic**: `isGlobalByPath` now also recognizes the pnpm 11 global virtual store pattern (`…/pnpm/store/…/links/…`) as a safety net when `PNPM_HOME` is not in the environment. - **Never classify as local without positive evidence**: a local (project-dependency) install always has a lockfile above the CLI's install location. Without that evidence, the upgrade now degrades to `npm i -g vercel@latest` executed from a temp dir — a potentially suboptimal suggestion, but one that cannot mutate the user's cwd. - **Crash-proof entrypoint resolution**: `realpath(process.argv[1])` failures (e.g. virtual filesystem snapshot paths in the native binary — the class of crash fixed for natives in #16581) no longer throw out of detection; they degrade to the safe global fallback. - **Prompt guard**: the post-command update notifier is skipped when the command was `upgrade`, mirroring the existing `canAutoUpdate` guard. ### Impact Every pnpm 11 global install of the CLI is affected, on all released versions including current latest — and the population grows as pnpm 11 adoption spreads (each `pnpm add -g vercel` under pnpm 11 creates the broken-detection layout). #16534 fixed the pnpm ≤10 workspace case but predates pnpm 11's layout. ### Test Plan - Unit tests covering: pnpm 11 isolated layout, legacy `global/5` layout, `PNPM_HOME` prefix anchoring (no substring false-positives), entrypoints outside `PNPM_HOME`, and the unrecognized-layout degradation (34 tests passing in `get-update-command`, `updates`, and `upgrade` suites) - `tsc --noEmit`, biome lint, prettier: clean - Empirical: bug reproduced pre-fix on both a long-lived dev machine and a fully reset clean machine; failure mechanism verified step-by-step against pnpm 11.7/11.9 layouts ### Follow-ups (not in this PR) - Post-install version verification: the success message currently reports the pre-resolved target version, not what was actually installed (observed divergence when pnpm's `min-release-age` gated the newest version: "upgraded to v54.18.7" while 54.18.6 was installed) - bun/vlt global installs are not detected (`scanParentDirs` can return them but `GlobalCliType` doesn't model them) - Longer term: distribution-channel awareness baked in at build time (native binary self-replacing; PM-distributed builds printing rather than executing), eliminating install-method forensics entirely

[frameworks] Source the framework list from the frameworks manifest (#16975) ### What Replaces the hand-written framework array in `@vercel/frameworks` with `frameworks.json`, sourced from the frameworks manifest (`https://api-frameworks-two.vercel.sh/v1/frameworks.json`, see vercel/api#78614). - `frameworks.json` is a **build artifact**: fetched by `build.mjs`, shipped in `dist/`, not checked into git. The fetch is fatal only when no previously fetched copy exists (`FRAMEWORKS_SKIP_MANIFEST_REFRESH=1` reuses the existing copy). Unit tests assert the manifest exists and is fully interpretable. - `src/manifest.ts` interprets declarative descriptors (`outputDirName`, `defaultRoutes`) into the runtime functions the `Framework` type requires. Unknown descriptor types throw `UnsupportedFrameworkEntryError` — the forward-compat hook for later PRs. ### Compat All existing exports are unchanged in shape (`frameworks` is now typed `readonly Framework[]` instead of a literal tuple; no in-repo consumer relied on the literals). The manifest currently adds one entry over the previous list: `tanstack-start-lovable` (intentional — a platform-import variant carrying the new `platform` field, now typed on `Framework` and validated by the schema test). ### Part of a stack Extracted from #16939 (kept open as the reference artifact for the full design). Follow-ups: 1. **This PR** — manifest as build artifact + interpreter 2. Runtime resolver API (`resolveFrameworks()`, remote fetch + cache, `minCliVersion`/`failOnStale` gating) 3. CLI wiring (`vc build` consumes the resolved list, upgrade warnings, build-container detection) ### Testing - 7 new unit tests (`manifest.unit.test.ts`): pinned manifest exists + interpretable, descriptor interpretation, override precedence, manifest-only field stripping - Existing schema/logo/unique/example suites pass unchanged against the interpreted list (strict `additionalProperties` validation retained) - Also fixes the pre-existing Node 24 failure in `frameworks.unit.test.ts` (`util.isString` was removed; replaced with a type guard) --------- Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com> Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>

[cli] Send gitMetadata.rootDirectory on deploy (#17344) ## Summary - Add `gitMetadata.rootDirectory`: path of the deployed project directory relative to the detected git repository root (`""` at repo root) - Resolve `.git/config` from the git toplevel so subdirectory deploys still attach `remoteUrl` - Keep this separate from the project `rootDirectory` setting and from user `--meta` ## Test plan - [x] `npx vitest run test/unit/util/deploy/create-git-meta.test.ts` (32 passed) - [ ] Deploy from a monorepo subdirectory and confirm the deployment has `meta.gitRootDirectory` matching that path (after API PR is deployed) Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com>

fix(ci): install Go toolchain for packages depending on ipc-proxy and harden Go download (#17088) Fixes flaky CI failure unrelated to PR #17079. **Failing job:** https://github.com/vercel/vercel/actions/runs/29277311707/job/86909622217 – `Unit / CLI (mac/node20) [7/7]` **Root cause:** - `turbo run ... --filter=vercel` builds the CLI which depends on `@vercel/go` → `@vercel-internals/ipc-proxy`. - `ipc-proxy` compiles Go cross-arch binaries during its build. - Workflow only installed Go when `matrix.packageName == '@vercel-internals/ipc-proxy'`, not for `vercel` CLI. - On macOS runners without system Go, `internals/ipc-proxy/build.mjs` fell back to downloading Go via `fetch()`, which flaked: ``` Downloading Go 1.23.12: https://dl.google.com/go/... TypeError: terminated at Fetch.onAborted ``` leaving a corrupted `/tmp/vercel-ipc-proxy-go-1.23.12`. Retry checked only `bin/go` existence, so it reused the corrupt GOROOT: ``` proxy.go:17:2: package context is not in std (.../src/context) ``` → build failed → turbo failed → job failed after 2 attempts. This is reproducible on `main` for any PR that triggers CLI unit chunks on mac. **Fix:** 1. **`utils/chunk-tests.js`** – add `needsGo` detection mirroring `needsRust`: - `GO_BUILD_ROOTS = { '@vercel-internals/ipc-proxy', '@vercel/go' }` - Packages depending on those roots (notably `vercel` CLI) now get `needsGo:true` in the chunk matrix. 2. **`.github/workflows/test.yml`** – install Go when `matrix.needsGo == true` for both `unit-test` and `e2e-test` jobs, preventing the network fallback on CI. 3. **`internals/ipc-proxy/build.mjs`** – harden the fallback for local/dev: - Validate cached GOROOT by reading `src/context/context.go`; if missing, re-download. - Retry download 3× with exponential backoff and `AbortSignal.timeout(120s)`. - Clean dest dir on failure to avoid poisoning retries. - Add timeout to `hasSystemGo()`. **Test plan:** - [ ] Verify `TEST_TYPE=unit node utils/chunk-tests.js | jq '.[] | select(.packageName=="vercel" and .runner=="macos-14") | .needsGo' | uniq` → `true` - [ ] CI: mac unit jobs for CLI now install Go, no longer Downloading Go log line - [ ] Existing `.github/workflows/test.yml` still passes on linux/mac/win Resolves flake seen in https://github.com/vercel/vercel/actions/runs/29277311707/job/86909622217

[backends] Align TypeScript typecheck behavior with @vercel/node (#17334) Part of the backends parity work (follows #17283, #17284, #17286). Mirrors the `@vercel/node` builder's typecheck behavior (`packages/node/src/typescript.ts`, a ts-node fork) so projects moving from the framework wrapper builders (`@vercel/express` et al.) to `@vercel/backends` see the same typecheck results, including historically shipped leniencies: - tsconfig.json is discovered walking up from the **entrypoint**, not `workPath` - Diagnostics 6059/18002/18003 are ignored - When `target` is not set, it defaults based on the Node.js major version (new optional `nodeVersionMajor` on `TypescriptOptions`) - When `module` is not set, `NodeNext` resolution is used and `strict` is forced off - Emit-oriented options (`outFile`, `composite`, `incremental`, ...) are dropped - `esModuleInterop` defaults to true only when unset - tsconfig option errors are fatal only when `noEmitOnError` is set - The user's `typescript` install is preferred; the bundled one is a fallback ## Verification - `pnpm type-check` in `packages/backends`: pass - `pnpm vitest run test/unit.build.test.ts test/unit.find-entrypoint.test.ts test/unit.post-build-entrypoint.test.ts`: 25/25 pass

ci: detect releases via changesets state, not npm version lookup (#17269) ## Problem The binary release gate added in #17235 checks whether `packages/cli`'s version is already on npm: ```bash if npm view "vercel@$version" version >/dev/null 2>&1; then ... skip ``` That answers *"is this version published?"*, not *"will this push publish?"*. The committed version stays unpublished for the entire time the Version Packages PR is open, so **every feature push to `main` evaluated to `should-release-binary=true`** and built + published native packages for a version that was not being released. It only worked by accident on the Version Packages merge commit. ## Fix Detection now reads the pending changeset state using the same `@changesets/read` that `changesets/action` itself uses, mirroring the action's decision: it runs the publish script **only when zero pending changesets remain**. The npm lookup is demoted to answering "does this publish include `vercel`?" once a publish is already confirmed. ``` willPublish binary case false false feature push (changeset pending), version NOT on npm <-- was wrongly true false false feature push (changeset pending), version on npm true true zero changesets, vercel NOT on npm (Version PR merge) true false zero changesets, vercel already on npm (re-run) ``` ### Notes - **Empty frontmatter counts as pending.** The action has three outcomes, not two — an all-empty set hits `case hasChangesets && !hasNonEmptyChangesets` and does nothing. Both non-publish branches are non-publish, so `changesets.length === 0` is the correct rule, and docs/CI-only pushes correctly skip the binary. - **Malformed changesets throw**, failing the `determine` job rather than parsing as "zero changesets" (which would look like a publish). - **Pre mode is not reimplemented.** `.changeset/pre.json` has never existed in this repo's history; its presence now hard-fails with a pointer to `readChangesetState` in changesets/action rather than silently miscounting. - **`isPublishedOnNpm` distinguishes a clean E404 from ambiguous failures** (registry outage, auth) and retries, erring toward building natives — wasted CI beats publishing `vercel` without them. This matches the caveat in the [changesets/action README](https://github.com/changesets/action/blob/main/README.md) for custom publishing. Owned logic is 5 lines; everything that could drift is delegated upstream: ```js export async function readChangesetState(cwd = repoRoot, readChangesets) { await assertNotPreMode(cwd); const changesets = await (readChangesets ?? loadReadChangesets())(cwd); return { changesets }; } ``` ## Testing 27 tests in `test/utils/determine-release/index.test.js`, including a 7-row case matrix over every `.changeset` shape that can land on `main`, and a parity block that reimplements the action's `switch (true)` so upstream drift fails loudly. Mutation-tested to confirm the suite has teeth: | mutation | result | | --- | --- | | `willPublish = true` (the original bug) | 15 failed \| 12 passed | | count only non-empty changesets | 5 failed \| 22 passed | | pre-mode guard removed | 2 failed \| 25 passed | | restored | 27 passed | ``` $ npx vitest run --config vitest.config.mts test/utils/determine-release/index.test.js Tests 27 passed (27) $ node utils/determine-release.mjs 5 pending changeset(s) (3 non-empty); changesets/action will open/update the Version Packages PR instead of publishing. will-publish=false should-release-binary=false ``` ## Caveat The `should-release-binary=true` path is verified against fixtures and the replicated action switch, but **not** against a real merge commit with live npm — it can only be proven when this runs on `main`. The included `vercel` patch changeset is there to exercise it on the next Version Packages merge.

[cli] Pre-approve esbuild's build script in pnpm upgrade commands (#16940) ### Description When the Vercel CLI is installed via pnpm, `vc upgrade` runs `pnpm i -g vercel@latest`. pnpm v10+ requires approval to run dependency build scripts (esbuild's postinstall), so the upgrade either waits on an approval prompt or skips the script, depending on pnpm version and environment. ### Fix Append pnpm's `--allow-build` flag to global upgrade commands, pre-approving the one build script the install needs: - `vercel` installs → `pnpm i -g vercel@latest --allow-build=esbuild` - `@vercel/vc-native` installs → `--allow-build=@vercel/vc-native` (its postinstall selects the platform binary) - Local installs are untouched — the flag would persist the approval into the project's `pnpm-workspace.yaml`, and that policy belongs to the project owner - npm/yarn commands unchanged That's the whole change: one flag on the generated command string. `vc upgrade --dry-run` / `--json` show the updated command, so copy-pasting it also works. ### Scope of the approval (verified against pnpm 10.29.3) `--allow-build` on a global install approves that single invocation only — nothing is persisted to the user's global pnpm config, and it does not greenlight esbuild machine-wide or in their projects. The flag is also accepted when the named package ends up not needing a build, so it's harmless if esbuild ever drops its postinstall. ### Compatibility `--allow-build` requires pnpm >= 10.4. On older 10.x the install fails with an unknown-option error and the existing failure path prints the command for manual use. ### Testing - New real-pnpm integration test (`pnpm-allow-build.test.ts`): runs the actual pnpm binary against a `file:` fixture package with a postinstall script in isolated state, proving the approval gate fires without the flag and that `--allow-build` defuses it. Skips when pnpm < 10. - Command-string unit tests updated for the global pnpm and vc-native variants - `pnpm type-check` clean

feat(cli): native trampoline with JS fallback, drop postinstall (#17011) ## What Part 1 of 2. Make the CLI bin native-aware: resolve and spawn a `@vercel/vc-native-{platform}-{arch}` binary when present, otherwise no-op into the existing JS CLI. This release is a no-op — no `optionalDependencies` are wired, so `resolveNative()` always returns null and the CLI runs as JS exactly as before. The point is to confirm the JS path is unaffected at scale before part 2 wires the release flow to build/publish natives before `vercel`.