start-local.ps1 failed on a machine that had everything it needed, and then blamed the one thing that was definitely not the problem: "the newest version nvm has installed is too old. Install a newer one" — printed on a machine holding 26.7.0 and 24.13.1, both well past the floor.
nvm use latest does not mean "the newest version I have installed". nvm-windows resolves latest against the remote release list, and newest is the alias for the newest installed. The docstring stated the opposite and the code was written against it. Here that resolved to 26.8.1, which is not installed, so nvm reported activation error: Version not installed, left v18.16.1 running, and exited 0.
Two things had to change, and fixing either alone leaves it broken.
The version asked for is now pinned in NODE_VERSION rather than chosen by alias, so two machines run the same Node instead of whatever each happens to have installed, and there is one line to bump for both entry points. The alias names are recorded in the docstring anyway, because latest and newest are easy to swap back by accident and the difference is the whole of this bug.
Use-Node no longer treats an alias as automatically successful. That special case is why the error was wrong rather than merely unhelpful: it short-circuited on $Version -eq 'latest' regardless of what was running, swallowing nvm's activation error — which the function had already captured in $output for exactly this purpose — and returned success holding v18. The floor check downstream then reported the only explanation left to it. An alias switch is now verified against nvm's own report, so a failure says what nvm said.
Keeping that half matters even with a pinned version, because no caller passes an alias today. The bug was someone reaching for one, and the next person reaching for one gets a truthful failure rather than a confident wrong answer.
The floor check survives as a backstop against pinning NODE_VERSION below 20, and its message now says that rather than describing installed versions — a version that is not installed is Use-Node's error to report, and it reports nvm's reason.
Verified from a real v18.16.1 baseline: the pinned switch takes 18.16.1 to 26.7.0; a concrete version that is not installed throws with nvm's reason; latest throws instead of silently succeeding. start-local.ps1 then runs the whole way through — Node switch, migrations, backend build, ready. Parse check clean.
Shared by start-local.ps1 and run-tests.ps1, so this broke both and fixes both.
`start-local.ps1` failed on a machine that had everything it needed, and then blamed the one thing that was definitely not the problem: "the newest version nvm has installed is too old. Install a newer one" — printed on a machine holding 26.7.0 and 24.13.1, both well past the floor.
`nvm use latest` does not mean "the newest version I have installed". nvm-windows resolves `latest` against the remote release list, and `newest` is the alias for the newest installed. The docstring stated the opposite and the code was written against it. Here that resolved to 26.8.1, which is not installed, so nvm reported `activation error: Version not installed`, left v18.16.1 running, and exited 0.
Two things had to change, and fixing either alone leaves it broken.
The version asked for is now pinned in `NODE_VERSION` rather than chosen by alias, so two machines run the same Node instead of whatever each happens to have installed, and there is one line to bump for both entry points. The alias names are recorded in the docstring anyway, because `latest` and `newest` are easy to swap back by accident and the difference is the whole of this bug.
`Use-Node` no longer treats an alias as automatically successful. That special case is why the error was wrong rather than merely unhelpful: it short-circuited on `$Version -eq 'latest'` regardless of what was running, swallowing nvm's `activation error` — which the function had already captured in `$output` for exactly this purpose — and returned success holding v18. The floor check downstream then reported the only explanation left to it. An alias switch is now verified against nvm's own report, so a failure says what nvm said.
Keeping that half matters even with a pinned version, because no caller passes an alias today. The bug was someone reaching for one, and the next person reaching for one gets a truthful failure rather than a confident wrong answer.
The floor check survives as a backstop against pinning `NODE_VERSION` below 20, and its message now says that rather than describing installed versions — a version that is not installed is `Use-Node`'s error to report, and it reports nvm's reason.
Verified from a real v18.16.1 baseline: the pinned switch takes 18.16.1 to 26.7.0; a concrete version that is not installed throws with nvm's reason; `latest` throws instead of silently succeeding. `start-local.ps1` then runs the whole way through — Node switch, migrations, backend build, ready. Parse check clean.
Shared by `start-local.ps1` and `run-tests.ps1`, so this broke both and fixes both.
Closes #198
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`start-local.ps1` failed on a machine that had everything it needed, and then blamed the one thing that was definitely not the problem: "the newest version nvm has installed is too old. Install a newer one" — printed on a machine holding 26.7.0 and 24.13.1, both well past the floor.
`nvm use latest` does not mean "the newest version I have installed". nvm-windows resolves `latest` against the remote release list, and `newest` is the alias for the newest installed. The docstring stated the opposite and the code was written against it. Here that resolved to 26.8.1, which is not installed, so nvm reported `activation error: Version not installed`, left v18.16.1 running, and exited 0.
Two things had to change, and fixing either alone leaves it broken.
The version asked for is now pinned in `NODE_VERSION` rather than chosen by alias, so two machines run the same Node instead of whatever each happens to have installed, and there is one line to bump for both entry points. The alias names are recorded in the docstring anyway, because `latest` and `newest` are easy to swap back by accident and the difference is the whole of this bug.
`Use-Node` no longer treats an alias as automatically successful. That special case is why the error was wrong rather than merely unhelpful: it short-circuited on `$Version -eq 'latest'` regardless of what was running, swallowing nvm's `activation error` — which the function had already captured in `$output` for exactly this purpose — and returned success holding v18. The floor check downstream then reported the only explanation left to it. An alias switch is now verified against nvm's own report, so a failure says what nvm said.
Keeping that half matters even with a pinned version, because no caller passes an alias today. The bug was someone reaching for one, and the next person reaching for one gets a truthful failure rather than a confident wrong answer.
The floor check survives as a backstop against pinning `NODE_VERSION` below 20, and its message now says that rather than describing installed versions — a version that is not installed is `Use-Node`'s error to report, and it reports nvm's reason.
Verified from a real v18.16.1 baseline: the pinned switch takes 18.16.1 to 26.7.0; a concrete version that is not installed throws with nvm's reason; `latest` throws instead of silently succeeding. `start-local.ps1` then runs the whole way through — Node switch, migrations, backend build, ready. Parse check clean.
Shared by `start-local.ps1` and `run-tests.ps1`, so this broke both and fixes both.
Closes#198
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
start-local.ps1failed on a machine that had everything it needed, and then blamed the one thing that was definitely not the problem: "the newest version nvm has installed is too old. Install a newer one" — printed on a machine holding 26.7.0 and 24.13.1, both well past the floor.nvm use latestdoes not mean "the newest version I have installed". nvm-windows resolveslatestagainst the remote release list, andnewestis the alias for the newest installed. The docstring stated the opposite and the code was written against it. Here that resolved to 26.8.1, which is not installed, so nvm reportedactivation error: Version not installed, left v18.16.1 running, and exited 0.Two things had to change, and fixing either alone leaves it broken.
The version asked for is now pinned in
NODE_VERSIONrather than chosen by alias, so two machines run the same Node instead of whatever each happens to have installed, and there is one line to bump for both entry points. The alias names are recorded in the docstring anyway, becauselatestandnewestare easy to swap back by accident and the difference is the whole of this bug.Use-Nodeno longer treats an alias as automatically successful. That special case is why the error was wrong rather than merely unhelpful: it short-circuited on$Version -eq 'latest'regardless of what was running, swallowing nvm'sactivation error— which the function had already captured in$outputfor exactly this purpose — and returned success holding v18. The floor check downstream then reported the only explanation left to it. An alias switch is now verified against nvm's own report, so a failure says what nvm said.Keeping that half matters even with a pinned version, because no caller passes an alias today. The bug was someone reaching for one, and the next person reaching for one gets a truthful failure rather than a confident wrong answer.
The floor check survives as a backstop against pinning
NODE_VERSIONbelow 20, and its message now says that rather than describing installed versions — a version that is not installed isUse-Node's error to report, and it reports nvm's reason.Verified from a real v18.16.1 baseline: the pinned switch takes 18.16.1 to 26.7.0; a concrete version that is not installed throws with nvm's reason;
latestthrows instead of silently succeeding.start-local.ps1then runs the whole way through — Node switch, migrations, backend build, ready. Parse check clean.Shared by
start-local.ps1andrun-tests.ps1, so this broke both and fixes both.Closes #198
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
latest(#198)