Found verifying the #330 / #323 / #334 fixes against 0.24.0-rc.5 in an adopter project. Those three are confirmed fixed — this is a new defect the #330 fix introduced.
What
link correctly no longer deletes package-lock.json (#330). But unlink repins only the manifests, so the lockfile keeps its pre-release resolution — private-registry tarball URLs and -rc versions — in a tracked file.
Before the #330 fix this could not happen: link deleted the lockfile, so the post-unlink npm install regenerated it from the public registry. Removing the deletion closed one hole and opened another.
Repro
link --version 0.24.0-rc.5 # package-lock.json correctly preserved
npm install # lockfile now resolves from the private registry
unlink --to 0.23.2
package.json and pyproject.toml are repinned correctly:
package.json:12: "@metaobjectsdev/cli": "0.23.2",
pyproject.toml:34: "metaobjects==0.23.2",
but the lockfile is untouched — 10 hits:
package-lock.json:9: "@metaobjectsdev/cli": "0.24.0-rc.5",
package-lock.json:437: "resolved": "https://<registry>/api/packages/<owner>/npm/%40metaobjectsdev%2Fcli/-/0.24.0-rc.5/cli-0.24.0-rc.5.tgz",
…
unlink then fails its own final check:
✗ unlink left pre-release references behind (listed above) — fix them before pushing
The detector is right, and this is a good demonstration that it works — the failure is real, not a false positive. But unlink reports it as something the user must go fix by hand, without saying that the fix is simply npm install.
Impact
npm ci on another machine, or in CI, resolves straight from the lockfile — so a committed lockfile in this state sends every other build to a private registry it cannot reach. That is the exact failure mode the detector exists to prevent, and it now survives a full link → unlink cycle.
Also stale
The remediation text printed on failure still describes the old behaviour:
detect-prerelease-pins.sh:358:
That removes the registry config, repins every vendor dependency, drops the lockfile,
and re-runs this check.
unlink no longer drops the lockfile, so this now tells the user something untrue at precisely the moment they are trying to work out what is wrong.
Suggested fix
unlink already knows which ecosystems it touched. After repinning, either re-run the install to regenerate the lockfile against the public registry, or — if running installs from unlink is unwanted — print the required command explicitly and make the final check's message say the lockfile is the residue:
unlinked. Run to complete: npm install
Worth applying to the other lockfiles it used to delete for the same reason (uv.lock, poetry.lock, Pipfile.lock, packages.lock.json).
Confirmed fixed in the same run, for the record
Still open from the #330 comment thread
link prints python uv lock && uv sync unconditionally when Python is detected. A pip/venv-managed project has no uv.lock; following it introduces uv as a side effect of trying an RC. The npm/bun half of #330 was fixed (npm install guidance no longer assumes a deleted lockfile), but the Python axis appears unchanged.
Found verifying the #330 / #323 / #334 fixes against
0.24.0-rc.5in an adopter project. Those three are confirmed fixed — this is a new defect the #330 fix introduced.What
linkcorrectly no longer deletespackage-lock.json(#330). Butunlinkrepins only the manifests, so the lockfile keeps its pre-release resolution — private-registry tarball URLs and-rcversions — in a tracked file.Before the #330 fix this could not happen:
linkdeleted the lockfile, so the post-unlinknpm installregenerated it from the public registry. Removing the deletion closed one hole and opened another.Repro
package.jsonandpyproject.tomlare repinned correctly:but the lockfile is untouched — 10 hits:
unlinkthen fails its own final check:The detector is right, and this is a good demonstration that it works — the failure is real, not a false positive. But
unlinkreports it as something the user must go fix by hand, without saying that the fix is simplynpm install.Impact
npm cion another machine, or in CI, resolves straight from the lockfile — so a committed lockfile in this state sends every other build to a private registry it cannot reach. That is the exact failure mode the detector exists to prevent, and it now survives a fulllink→unlinkcycle.Also stale
The remediation text printed on failure still describes the old behaviour:
unlinkno longer drops the lockfile, so this now tells the user something untrue at precisely the moment they are trying to work out what is wrong.Suggested fix
unlinkalready knows which ecosystems it touched. After repinning, either re-run the install to regenerate the lockfile against the public registry, or — if running installs fromunlinkis unwanted — print the required command explicitly and make the final check's message say the lockfile is the residue:Worth applying to the other lockfiles it used to delete for the same reason (
uv.lock,poetry.lock,Pipfile.lock,packages.lock.json).Confirmed fixed in the same run, for the record
package-lock.jsonpreserved byte-identically throughlink.buildConfigFieldLAN default; while linked it flagged only the genuine registry URL and the real-rcpins.librariesloader option, sometaobjects::ai::LlmCallBasecannot be loaded at all #332 / TypeScript CLI has nolibrarieskey, someta gencannot load a shipped library the registered generators consume #333 — Java gainedEmbeddedLibrary/LibrarySources/ a MavenLoaderParam, plus aTraceHelperOnShippedLibraryTestthat drives the generator from the SHIPPED base; the TS CLI now carrieslibraries. C# picked it up too.Still open from the #330 comment thread
linkprintspython uv lock && uv syncunconditionally when Python is detected. A pip/venv-managed project has nouv.lock; following it introduces uv as a side effect of trying an RC. The npm/bun half of #330 was fixed (npm installguidance no longer assumes a deleted lockfile), but the Python axis appears unchanged.