bermudalamb/redefined-designs
1
0
Fork 0
Code Issues 2 Pull Requests 1 Actions Packages Projects 3 Releases Wiki Activity

fix(local): install dependencies when the lockfile changes, not only when node_modules is absent #348

Merged
bermudalamb merged 2 commits from fix/local-install-skips-new-dependencies into main 2026-09-10 10:07:00 -05:00
Conversation 0 Commits 2 Files Changed 1
+29 -4
2 Commits
Author SHA1 Message Date
bermudalamb c9829d4384 Merge branch 'main' into fix/local-install-skips-new-dependencies
Linting / lint (pull_request) Successful in 2m59s
Details
SonarQube Analysis / sonarqube (pull_request) Failing after 27m39s
Details
2026-09-10 09:56:43 -05:00
synAdminandClaude Opus 5 46f7cb8612 fix(local): install dependencies when the lockfile changes, not only when node_modules is absent
Linting / lint (pull_request) Successful in 3m41s
Details
SonarQube Analysis / sonarqube (pull_request) Failing after 25m18s
Details 
Starting the stack locally failed to build with four copies of

    error TS2307: Cannot find module '@simplewebauthn/server'

naming a package that is right there in package.json. That reads as a broken checkout rather than a missing install, which is why it costs more than it should.

The cause is one line in Install-IfMissing. It asked whether node_modules existed and returned early if it did, which is true for anyone who has ever run the script. So a branch that ADDS a dependency never installs it: the pull brings a new package.json and a new lockfile, the script says dependencies already installed, and the build then fails on an import the source is entirely right to make.

The passkeys work is what surfaced it, adding @simplewebauthn/server to the backend and @simplewebauthn/browser to the frontend, but nothing about it is specific to those. Any dependency added on any branch would have done the same, and the failure would have looked equally unrelated to its cause each time.

It now compares timestamps instead. npm writes node_modules/.package-lock.json describing exactly what it put there, so holding that against package-lock.json answers the question actually being asked: is what is installed what is currently asked for. A pull that changes dependencies makes the lockfile newer and this notices; a pull that does not leaves the check skipping the install exactly as before, which is the whole reason the check exists.

Both branches were exercised against the real working tree: stale before installing, up to date after.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-10 08:58:22 -05:00