chore: sync package-lock.json with package.json

[harperfastbot]

package-lock.json has drifted from package.json. This PR regenerates the lock file.

Generated by the Sync Lock File workflow.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	structon@​1.0.8 ⏵ 1.0.7	-16			+3

View full report

[cb1kenobi]

Barber AI review — ⚠️ 1 open issue

High: this "sync" is a downgrade, and it reverts the structon fix for #1441.

The lockfile change is mechanically correct — package.json pins "structon": "1.0.7" exactly, the lock resolved 1.0.8, so regenerating pulls it back to 1.0.7. But the resulting install is a downgrade of Harper's record-persistence encoder, not a no-op sync. main's lock installs 1.0.8 today; merging this makes builds install 1.0.7.

Where the drift came from

#2179 "Pin the load-bearing native and encoder dependencies" (merged ~1h ago) changed structon from ^1.0.7 to exact 1.0.7 while the lock already held 1.0.8. Pinning to the lower bound froze the version below what was installed. So the drift is real, but the fix direction is backwards: package.json should move to 1.0.8, rather than the lock moving to 1.0.7.

What 1.0.7 → 1.0.8 gives up

Diffed the two published tarballs. Three fixes are lost, all in RecordEncoder's base (resources/RecordEncoder.ts:9 — import { createStructon } from 'structon'):

1. isCompatible forwarding — this is the #1441 fix, and it names Harper explicitly. 1.0.8's _saveTypedStructures does:

   // Forward isCompatible as the second arg, matching msgpackr's own pack call site.
   // ... without forwarding it, a saveStructures implementation that runs an optimistic
   // CAS on the parameter (e.g. Harper's RocksDB override) sees `undefined` and a
   // concurrent same-length save silently clobbers the previously persisted struct.
   // See HarperFast/harper#1441.
   return this.saveStructures(structures, structures.isCompatible);

   1.0.7 calls this.saveStructures(structures) with no second argument. Harper's RocksDB saveStructures override is precisely the CAS implementation that comment describes.

2. Declined-save retry. 1.0.8 will not return a struct encoding whose structure id came from a declined save — it reloads and re-mints once, then surfaces sustained contention. 1.0.7 returns bytes referencing an id nobody persisted.

3. cbor-x SharedData shape handling. Per 1.0.8's own comment, without it the object branch "reads no named/typed and silently clears the whole dictionary."

The existing guard won't catch this

integrationTests/database/heterogeneous-ingest.test.ts was written so "a structon regression or an accidental downgrade can't silently reintroduce the loss" — but it is calibrated at < 1.0.7. A downgrade to 1.0.7 passes it. Worth re-pinning that guard to the version actually required.

build-tools/check-shrinkwrap-pins.mjs (added in #2179) is canary-based over ['@harperfast/rocksdb-js', 'fastify', '@aws-sdk/client-s3'], so it doesn't cover structon either.

Suggested resolution

Set "structon": "1.0.8" in package.json and regenerate, instead of merging this lock downgrade. If 1.0.7 is deliberate, that's worth stating explicitly — it reverts a fix landed for a Harper-specific data-loss issue.

---

🤖 Barber AI · claude-opus-5 · tarball diff and version history verified against the npm registry

[cb1kenobi]

High: this line is a downgrade of the record-persistence encoder, and it reverts the harper#1441 fix

Anchoring the finding here so it is trackable — full analysis in this review.

In short: package.json pins structon to exactly 1.0.7, so regenerating the lock is mechanically correct — but main installs 1.0.8 today, and structon is the base of RecordEncoder (resources/RecordEncoder.ts:9). Merging this changes what ships.

structon@1.0.7 calls this.saveStructures(structures) with one argument (index.js:165); 1.0.8 calls this.saveStructures(structures, structures.isCompatible) (index.js:205) and cites harper#1441 in its own source comment. With isCompatible undefined, Harper's RocksDB override at RecordEncoder.ts:329-334 takes the else if (existingStructures && existingStructures.length !== isCompatible) branch — and for the {named, typed} typed-struct shape there is no .length, so undefined !== undefined is false, the guard never fires, and putSync runs unconditionally. The typed-struct CAS is inert on 1.0.7.

The drift originates in #2179, which pinned ^1.0.7 to exact 1.0.7 while the lock already held 1.0.8 — i.e. pinned to the lower bound. Suggested fix: set "structon": "1.0.8" in package.json and regenerate, rather than merging this lock downgrade.

---

🤖 Barber AI · claude-opus-5 · verified against both published tarballs and the local v5.2.2 checkout