Repository navigation
fix: sync package-lock.json to the plugin version and gate the drift (#16) - #17
Merged
Merged
Conversation
…16) package-lock.json recorded packages/plugin at 0.3.1 while its package.json moved to 0.3.4 across #8, #13 and #15. Nothing caught it: npm ci reconstructs the dependency tree, and a workspace member's own `version` field is not part of it, so the public lockfile claimed a version the plugin had not been for three releases. The one-command repair is the one that must not run. `npm install --package-lock-only` fixes the member entry and, in the same pass, rewrites the `../odoo-bot/middleware/packages/plugin-api` file: external from whatever core checkout sits next to this repo on the developer's disk (0.1.0 committed, 1.10.0 here) — machine state that must never land in a public lockfile. So: - Surgically bump ONLY the packages/plugin lockfile entry 0.3.1 -> 0.3.4. The external stays exactly as committed; no other member had drifted. - Add scripts/check-lock-sync.mjs: a read-only checker that asserts, for every workspace member (root included), lockfile version == package.json version, and prints the exact by-hand fix while forbidding the regeneration that leaks the local core checkout. It refuses any workspaces pattern it cannot safely expand -- outside-repo, a missing named member, or an unsupported glob -- rather than silently checking fewer members than the workspace has. - Wire it into `npm run package` (build-zip.mjs) and into CI before `npm ci`, where npm ci genuinely cannot see the drift. Add an `npm run check:lock` script. - Test packages/plugin/test/lockSync.test.ts covers discovery, drift, the external-is-never-a-member invariant, the error message, and that both wiring points are actually in place. Version stays 0.3.4 -- lockfile and tooling only, no release, no hub publish.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #16.
The bug
package-lock.jsonrecordedpackages/pluginat 0.3.1 while itspackage.jsonmoved on to 0.3.4 across #8, #13 and #15. Nothing caught it — and nothing could:npm cireconstructs the dependency tree, and a workspace member's ownversionfield is not part of that tree. A drifted lockfile installs cleanly, tests green, packages a correct ZIP, and quietly tells every reader of a public repository that this plugin is a version it has not been for three releases.Why this isn't just
npm install --package-lock-onlyThat command repairs the member entry and, in the same pass, rewrites
from whatever core checkout happens to sit next to this repo on the machine it runs on — committed as
0.1.0, but1.10.0on the machine that shipped this fix. npm has no way to know thatfile:target is a working tree rather than a pinned dep, so the only safe tool is one that cannot write at all.What this PR does
packages/pluginlockfile entry0.3.1 → 0.3.4(one line). The external stays exactly as committed; no other member had drifted.package-lock.jsonlockfile version == package.json version. Prints the exact by-hand fix and forbids the regeneration that leaks the local core checkout. Refuses anyworkspacespattern it cannot safely expand — outside-repo, a missing named member, or an unsupported glob — rather than silently checking fewer members than the workspace has.scripts/check-lock-sync.mjsnpm run packageand into CI beforenpm ci(wherenpm cigenuinely cannot see the drift). Addnpm run check:lock.build-zip.mjs,ci.yml,package.jsonpackages/plugin/test/lockSync.test.tsCONTRIBUTING.mdVersion stays 0.3.4 — lockfile and tooling only. No release, no hub publish.
Verification
Run locally against
pgvector/pgvector:pg16and coremain:npm run check:lock→✓ 6 workspace entries checkednpm cifrom a clean tree → exit 0npm run typecheck && npm run build→ cleannpm test→ 1371 pass, 0 fail, 0 skipped (827 + 76 + 468)npm run package→omadia-dev-platform-0.3.4.zip, payload verified, ZIPpackage.jsonreads@omadia/dev-platform 0.3.4Mutation-checked that the gates bite: reintroducing the drift fails the CLI, the packaging gate and the suite; removing the
build-zip.mjscall or reordering the CI step each fails a dedicated wiring test.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.