chore(ui): pin nitro instead of tracking the latest dist-tag - #2321
Open
Rajarshi Datta (rajarshidattapy) wants to merge 1 commit into
Open
chore(ui): pin nitro instead of tracking the latest dist-tag#2321Rajarshi Datta (rajarshidattapy) wants to merge 1 commit into
Rajarshi Datta (rajarshidattapy) wants to merge 1 commit into
Conversation
`nitro` was the only floating specifier in the workspace — a grep for
`"latest"`, `"*"` or `"x"` across every package.json matched this one line and
nothing else.
The lockfile holds the resolution today, so ordinary installs are reproducible.
The exposure is any operation that refreshes the lock: `pnpm update`, a bot's
lock refresh, or a conflict resolved by regenerating. Each of those silently
accepts whatever the newest published `nitro` is, with no range to reject it and
no signal in the diff beyond a lockfile line.
That matters more than usual here for two reasons. `nitro` is the server runtime
under the TanStack Start dashboard and is imported directly by the build
(`ui/vite.config.ts` does `import { nitro } from "nitro/vite"`), so a surprise
version lands on the build and request path rather than in a leaf utility. And
`latest` currently resolves to `3.0.260610-beta` — the dist-tag points at a v3
pre-release, so the floating specifier is tracking a moving beta.
Pin it exactly at the version already installed. An exact pin rather than a
caret range because caret ranges over a pre-release only match pre-releases of
the same major.minor.patch, which is both surprising and not what is wanted
here. This matches how the file already treats its other pre-release pins:
`h3` at `2.0.1-rc.22` and `@pierre/trees` at `1.0.0-beta.4`.
No dependency moves: the lockfile diff is the specifier string only, and the
resolved version is unchanged.
Fixes langchain-ai#2309
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2309.
Problem
This is the only floating specifier in the workspace —
grep -rn '": *"\(latest\|\*\|x\)"' --include=package.json .matches this line and nothing else.pnpm-lock.yamlholds the resolution today, so ordinary installs are reproducible. The exposure is any operation that refreshes the lock —pnpm update, a Dependabot/Renovate lock refresh, or a conflict resolved by regenerating. Each silently accepts whatever the newest publishednitrois, including a new major, with no range to reject it and no signal in the diff beyond a lockfile line.Two things make it sharper than a typical floating pin:
nitrois the server runtime under the TanStack Start dashboard and is imported directly:ui/vite.config.ts:7doesimport { nitro } from "nitro/vite", and it is configured at:178. A surprise version lands there, not in a leaf utility.latestcurrently resolves to a pre-release:3.0.260610-beta. The dist-tag points at a v3 beta, so this specifier is tracking a moving beta rather than a stable line.Change
Pin exactly at the version already installed:
Exact, not a caret range. The issue suggested
^3.x.y, but a caret over a pre-release only matches pre-releases of the samemajor.minor.patch— surprising semantics, and not the intent. Exact is also what this file already does for its other pre-release dependencies:h3is the closest precedent — same unjs ecosystem asnitro, pinned exactly at an rc.No dependency moves
The lockfile diff is the specifier string only. The resolved version is byte-identical before and after:
Regenerated with
pnpm install --lockfile-only; two files change by one line each.Verification
pnpm install --frozen-lockfile --filter open-swe-dashboard... --filter open-swe— "Lockfile is up to date, resolution step is skipped". This is the path every JS CI job takes, and it is the thing a package.json edit most easily breaks.3.0.260610-beta, unchanged.pnpm --filter open-swe-dashboard run typecheck— exit 0.pnpm --filter open-swe-dashboard run test— 66 files, 303 tests passed.One note on the test evidence, since I hit it and it would be misleading to omit: two of my local runs of the full UI suite were flaky under load on Windows — one reported 6 worker errors, another a 5000ms timeout in
src/routes/-admin.test.tsx. Run in isolation that file passes on this branch and on unmodifiedmain, so it is machine contention rather than anything here. Worth saying plainly: since the resolved dependency tree does not change at all, this PR cannot affect test behaviour either way.