A plain lockfile key (`@scope/a@1.0.0`) records no registry, so the
reuse gate read its registry from the current scope route. Routing the
scope to another registry was invisible: the lockfile stayed fresh, the
install went headless, and the locked versions and children were
fetched from the new registry with the old integrity. The install
failed where resolving against the new registry would succeed.
The workspace state now records the scope routes an install resolved
the lockfile under (registryRoutes). A resolving unfiltered install
records the routes it ran under; a frozen or filtered install keeps the
previous record while a plain key still sits under a moved route. The
default registry is not recorded: switching it is routinely a mirror
switch and would resolve every unscoped package again.
The registry context carries those routes as the provenance of plain
keys. The reuse gate reads a plain key's registry from them, so a key
under a moved scope is refused, loses its pin, and resolves again from
its range against the new registry. In pacquet the subtree-reuse walk
also refuses a subtree holding a moved key, because a reused parent
seeds its children with exact pins and only its fresh manifest carries
the ranges. A plain key under a moved route marks the lockfile stale
for a resolving install; --frozen-lockfile installs it as recorded.
A route change is a settings drift for the repeat-install shortcut.
The route: entries of registryPrefixes are redundant with the new
record and are dropped (that record is unreleased).
Closes https://github.com/pnpm/tasks/issues/209
Zoltan Kochan
4f83ee223e