The npm publish workflow of tannermidd/pi-pocket has been modified. Commit db1e531, merged at 22:22 UTC on October 30, 2026, merged PR #229 (branch fix/publish-npm-11), pinning the npm client to 11 and changing the workflow to stop before publishing if npm-shrinkwrap.json is not present in the package. The only file the change was made in is .github/workflows/publish.yml, and the size of the change is 13 lines added and 1 line deleted.
npm-shrinkwrap.json is a file that fixes dependency versions exactly as they are at install time. The comment newly added to the workflow states that npm 12 leaves this file out of the package. If the latest npm is used as is, the release goes out without a lockfile, so the tested dependency versions are not handed over to the installer. The change has two parts. First, the npm installation is changed from npm install -g npm@latest to npm install -g npm@11, keeping the range that the comment says supports trusted publishing. Next, the output of npm pack --dry-run --json --ignore-scripts is checked for whether npm-shrinkwrap.json is included, and if it is not, a message saying that the dependency versions verified at install time will not be handed over is left behind, and the run is aborted with exit code 1. It is a safeguard against quietly shipping the wrong release before publishing.
However, the confirmed change is only in one place in the publish pipeline. There is no part that changed the application code or the package contents, and the check merely looks at whether the lockfile is in the list, so it does not look at whether the dependency versions inside it match the verified versions. The workflow still copies package-lock.json to npm-shrinkwrap.json before the check, so this check comes close to verifying whether that copy passes npm pack. The given record contains nothing about npm 12's release schedule or whether this commit has actually been reflected in a real release. In a situation where publishing can only continue if the way the new npm handles the lockfile is fixed, this is close to a defensive change put in as a means of preventing the loss of the lockfile.