prerelease-link.sh: deletes tracked lockfiles without warning, and prints npm-only install guidance for bun-managed projects

[dmealing]

Found while evaluating 0.24.0-rc.3 in an adopter project.

Two related defects in how link finishes up: it deletes tracked lockfiles, and the guidance it prints afterwards is npm-only even when the project is bun-managed. Together they push an adopter into swapping package manager as a side effect of trying a pre-release.

1. link deletes lockfiles that are tracked, without warning

The script is careful about tracked files everywhere else. .npmrc, NuGet.config and .mvn/* go into .git/info/exclude; pyproject.toml and pom.xml get a loud warning precisely because they are tracked by definition:

! pom.xml is tracked by definition — the managed block is committable; 'unlink' removes it

Lockfiles get neither. They are simply removed:

  dropped lockfile(s): bun.lock

bun.lock / package-lock.json are tracked in essentially every real project, so this is a destructive edit to committed state, reported in the same neutral tone as the configuration changes — and, unlike the managed blocks, it is not something unlink can put back.

Observed across three install roots:

$ git status --short
 D <app>/bun.lock
 D <console>/bun.lock
 D <scripts/docs>/bun.lock

Why it matters beyond the deletion

Dropping the lockfile turns a targeted pin into a full dependency re-resolution. For evaluating a pre-release that is the wrong default: it mixes "does the RC work" with "does a fresh resolve of every unrelated transitive dependency work", and any breakage lands in the same diff.

Restoring the lockfiles first and letting the package manager reconcile the changed manifest gives a much cleaner test. Doing that here moved exactly the 16 vendor packages and nothing else:

$ git checkout -- <app>/bun.lock && bun install
+ @metaobjectsdev/cli@0.24.0-rc.3
  ... 10 packages ...
16 packages installed

2. The post-link instructions assume npm

link always prints:

npm    rm -f package-lock.json && npm install

For a bun-managed project (a bun.lock, no package-lock.json) following that literally runs npm install, which creates a package-lock.json beside the deleted bun.lock and silently migrates the project to a different package manager and a different resolution. The .npmrc the script writes is read by both tools, so the install succeeds — it just quietly leaves the repo on npm.

Since link has already detected the lockfile — it names it in dropped lockfile(s): bun.lock — it has everything it needs to print the right command.

Suggested fix

• Do not delete lockfiles by default. Prefer repin-then-reconcile (bun install / npm install against the edited manifest), which is both less destructive and a better-isolated test. If a clean re-resolve is genuinely wanted, put it behind a flag.
• If a lockfile is deleted, warn when it is tracked, in the same register as the pom.xml / pyproject.toml warnings, and say that unlink cannot restore it.
• Derive the printed install command from the lockfile already detected: bun.lock → bun install, pnpm-lock.yaml → pnpm install, yarn.lock → yarn, else npm.

Related

#325 notes the lockfile-dropping set is inconsistent across nested roots. This issue is about the dropping itself (tracked-file destruction) and the manager-specific guidance, rather than which roots it reaches.

[dmealing]

The same defect has a Python axis, found evaluating 0.24.0-rc.3 in a pip/venv-managed adopter.

link prints uv-only guidance whenever Python is detected, with no check for what the project actually uses:

tools/prerelease/prerelease-link.sh:436:
    has_py    && say "python uv lock && uv sync"

The project in question has no uv.lock and manages its environment with a plain venv + pip. Following the printed guidance would have introduced uv as a side effect of trying a pre-release — the same "swap package manager to test an RC" outcome this issue already describes for bun.

What makes it clearly an oversight rather than an assumption: the script already knows the other Python toolchains exist, because it deletes their lockfiles a few hundred lines earlier:

tools/prerelease/prerelease-link.sh:228:
    uv.lock poetry.lock Pipfile.lock packages.lock.json; do

So the detection needed to print the right line is already there.

The install that actually worked, for reference — the RC resolved from the private index while everything else stayed on PyPI:

pip install -U \
  --index-url https://<registry>/api/packages/<owner>/pypi/simple \
  --extra-index-url https://pypi.org/simple \
  "metaobjects==0.24.0rc3"

Suggest keying the printed line off the detected lockfile / manifest rather than assuming uv: uv.lock → uv, poetry.lock → poetry, Pipfile.lock → pipenv, otherwise the pip form above.

[dmealing]

Fixed on main. Lockfiles are no longer dropped by default — --fresh opts in. Three reasons, and the third is the one that decided it: deletion is destructive to committed state; unlink cannot undo it; and it turns a targeted pin into a full re-resolution, so "does the RC work" and "does a fresh resolve work" land in one diff and neither is answered.

The install guidance now follows the detected package manager rather than assuming npm.