chore(deps): update all non-major dependencies - #154
Conversation
dawsontoth
left a comment
There was a problem hiding this comment.
The dependency bumps in this PR are fine — the committed lockfile is not. npm ci cannot install it, which is why Build, Format, Lint and Test are all red while commitlint (the only job that doesn't run npm ci) is green.
What's wrong
This is the recurring harper optional-dependency pruning issue, tripped here by harper 5.2.2 → 5.2.4. Re-resolving harper itself drops the alasql → react-native-fs optional subtree from the lockfile, but leaves the declaring optionalDependencies field in place, so npm ci demands 246 packages the lock no longer contains:
npm error code EUSAGE
npm error Missing: react-native-fs@2.20.0 from lock file
npm error Missing: react-native@0.84.1 from lock file
npm error Missing: @react-native/codegen@0.84.1 from lock file
... (246 total: react-native / metro / jest / babel entries)
Reproduced locally on ec3e03bc (Node 24.17.0, npm 11.13.0) — npm ci --ignore-scripts exits 1 with the identical error set.
Lockfile evidence: node_modules/harper is at 5.2.4 and node_modules/harper/node_modules/alasql@4.17.3 still declares optionalDependencies: {"react-native-fs": "^2.20.0"}, but the lockfile contains 0 react-native* package entries (main has 28). Total keys dropped 1655 → 1402.
The bumps themselves are good
I healed the lockfile locally with a single full npm install and everything passes:
| check | result |
|---|---|
npm ci |
exit 0 |
npm run build |
exit 0 (ESM + DTS) |
npm run lint |
exit 0 |
dprint check |
exit 0 |
npm test |
53 files / 345 tests passed |
So please don't drop any of the version bumps — only the lockfile needs regenerating.
Fix
One full (non---package-lock-only) npm install on top of this branch restores the subtree and makes npm ci pass:
npm install # keys 1402 -> 1648, react-native entries 0 -> 28
npm ci # exit 0
--package-lock-only does not fix it — the subtree is only materialized by a real reify. Note also that skipInstalls: false is not a fix for this (verified previously and retracted); what works is an actual second full install pass, e.g. via Renovate postUpgradeTasks, or regenerating locally and committing.
For reference, vite#41 takes the same harper 5.2.2 → 5.2.4 bump and is not affected (19 react-native entries retained, npm ci exit 0), so this is specific to how the resolution landed here, not to the harper version.
ec3e03b to
3030123
Compare
3030123 to
21da00c
Compare
The harper 5.2.2 -> 5.2.4 re-resolve dropped the alasql -> react-native-fs optional subtree from package-lock.json while leaving the declaring optionalDependencies field in place, so `npm ci` failed with 246 "Missing: ... from lock file" errors, taking Build, Format, Lint and Test down with it. commitlint stayed green because it is the only job that does not run `npm ci`. Regenerated with a single full `npm install`, which re-materializes the subtree; `--package-lock-only` never does. Purely additive: 246 entries restored, 0 removed, 0 version changes on pre-existing entries, package.json untouched. The only two pre-existing entries whose content changed are normalize-path and yaml, which gained optional/peer flags now that they are also reachable through the restored subtree (same version, same integrity). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Pushed Regenerated with a single full The diff is provably additive:
The only two pre-existing entries whose content changed at all are Local verification on the pushed tree (Node 24.17.0):
One note for whoever picks this up: I pushed the fix, so I can't approve my own commit — this needs a second pair of eyes to clear my earlier Worth fixing upstream rather than by hand each cycle. This is the third time this has hit a repo with a Also worth knowing: |
|
🎉 This PR is included in version 0.16.46 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Renovate generated this branch's lockfile without a full reify, so the `harper` bump pruned the optional `harper > alasql > react-native` subtree: 1403 keys / 0 `react-native` entries against 1649 / 28 on main. `npm ci` then failed EUSAGE with 246 `Missing:` entries, taking Build, Format, Lint and Test red while commitlint stayed green. One full `npm install` restores it. The result is purely additive against the Renovate lockfile — 246 added entries (exactly the 246 `npm ci` reported missing), 0 version changes, 0 removals — so none of the proposed bumps move. Verified on a clean slate (Node 24.19.0): npm ci, build, lint, dprint check, and 53 files / 345 tests all pass. This recurs on every `harper` bump and a Renovate rebase does not heal it (cf. #141, #154), which is why this is a manual commit on top. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This PR contains the following updates:
1.12.1→1.12.24.1.10→4.1.115.2.2→5.2.44.13.2→4.13.31.78.0→1.79.04.1.10→4.1.11Release Notes
HarperFast/skills (@harperfast/skills)
v1.12.2Compare Source
Documentation
d4cbc1a(45e12cb)vitest-dev/vitest (@vitest/coverage-v8)
v4.1.11Compare Source
🐞 Bug Fixes
View changes on GitHub
harperfast/harper (harper)
v5.2.4Compare Source
Regression fix: using a context after a mid-handler commit
Committing the current transaction mid-handler and then continuing to use the context — the pattern documented in the v5 migration notes and the 4.5.0 notes — started returning 500s on 5.2.1 and later.
releaseContext()(added in #2030 to stop a long-lived context pinning a completed transaction) setcontext.transaction = null, and the next touch threwCannot read properties of null (reading 'commit').On 5.2.3 this took out Central Manager's fabric connect and cluster create/delete for any non-super-user, because
getUserPermissions()commits the caller's transaction mid-request.A completed transaction now leaves a frozen, process-wide released placeholder in the slot:
commit()andabort()are no-ops and reads through it see the latest committed state — the behavior the slot had before #2030 — while retention stays O(1) per process. Every route that adopts a caller-supplied transaction or context refuses the placeholder rather than silently operating on it. (#2230, closes #2229)Data integrity
delete K; put Ktransaction — the shape a replace-all writer produces — could leave a follower holding a live, correct record with none of its secondary index entries: invisible to every indexed search, and not repairable by rewriting the record. Same-key writes now execute in the order they were staged, and a transaction applied from a leader stages its same-key writes in the leader's order. (#2235)invalidate,publish, crash-recovery replay, reload markers — installed a native handle without the per-handle reference bookkeeping, leaving the read-transaction count asNaNfor each consumer that reads it (commit(),doneReadTxn(),disregardReadTxn(),releaseContext()andabort()). Those transactions are also now visible to the long-transaction monitor. (#2232)Availability
NODE_STORAGEwalked the entire Harper root with an unbounded recursivePromise.all, holding a path, a dirent and a pendingstatfor every file at once. On a node with a large blob store the main thread grew about 72 MB/s until V8 aborted — and because the metric runs on the first analytics cycle after start, it happened on every boot (124 restarts observed on 5.2.3). The walk now streams each directory throughopendirand stats one file at a time. (#2242, fixes #2240)storage.debugLongTransactionsno longer breaks reads. With the flag on, anysearch()whose transaction had not opened its own read handle threwTypeError: Cannot read properties of undefined (reading 'push')and returned a 500 — the diagnostic broke exactly the reads an operator enables it to diagnose. (#2225, refs #2222)Configuration and observability
replication_receiveQueueHighWaterMarkis now a registered configuration setting, so the bounded replication receive queue added in harper-pro #735 can be tuned. (#2233)harper statusreports process uptime, andsystem_informationreturnsprocess_uptimein seconds in its time response. (#2209)Also in this release
Windows CI deflakes for early-hints deployment and the QA-782 LMDB control arm (#2227, #2243/#2248); promoted test coverage for streaming delivery and stream-error contracts (#2070) and six QA eviction/removal/reclaim data-integrity anchors (#1916); an in-repo guard for the new config registration; and a
package-lock.jsonsync.Full Changelog: HarperFast/harper@v5.2.3...v5.2.4
v5.2.3Compare Source
Blob durability — dangling references and in-flight readers
Two related fixes close windows where a committed record could point at blob bytes that were no longer on disk.
PENDING, or incomplete blob file. When the same record is later re-delivered by a base copy, Harper now repairs that existing file in place rather than writing a new orphan the duplicate-skipped record would never reference. The repair is fail-atomic — it holds the blob lock, writes and verifies a sibling temp file, flushes, and renames over the target — so a failed repair leaves the referenced file byte-for-byte unchanged. The orphan sweeper respects active repair locks. Adds the shared blob-header classifier and thereplication.blobGapReconnectMsconfig key consumed by harper-pro (#2177).stream()/bytes()time, a reader that resolved a record just before a concurrent write could open a file that was already gone — on the HTTP path thatENOENTlands after response headers are committed, reaching the client as a truncated body while every signal reports success. The delay is now configurable viastorage.blobRetentionand defaults to 2s, and reclamation is reference-aware so an in-flight reader can take a retention hold (#2145).Deploy — by reference, with a durable credential
harper deploygains two opt-ins that together let an app be deployed from its git repository instead of an uploaded payload:by_ref=true(orref=<committish>) resolves the app's GitHubowner/repoand commit from the local working copy (or from GitHub Actions env) and deploysgit+https://github.com/<owner>/<repo>.git#<sha>. Everything that could move is resolved client-side to a SHA — including an explicitref=, locally first and then viagit ls-remote— so cluster peers, which resolve the package independently, cannot diverge on a moved tag. An unpinnable ref fails closed rather than being sent as a name the cluster would resolve for itself, and an attached credential is pinned to the package host (#1850).setup=trueis a guided, client-side credential provisioning flow — whatharper loginis for auth, but for deploy tokens. It fetches the cluster's public key, sources a token (a fine-grained PAT, yourghsession, or an npm token), seals it locally into anenc:v1:envelope, and stores only ciphertext in the component-scoped secret tier. The plaintext never leaves the machine; the cluster decrypts in memory only at deploy/rollback time (#1851).package_componentstreams instead of base64package_componentreturned the whole component tarball as a base64 string inside the JSON envelope, peaking at roughly 4.7× the archive size resident in a shared (on Fabric, multi-tenant) Harper process, and hard-failing withERR_STRING_TOO_LONGonce the base64 result exceeded V8's string cap. The operation now streams the archive; project-resolution failures other thanENOENTare rethrown instead of being swallowed (#2152, #2150).Dependency pinning for load-bearing modules
A caret range does not bind the version that reaches a running node: harper-pro, a rebuilt container, or a plain
npm installof publishedharpercould resolve a newer native or encoder dependency with no Harper PR and no human merge. The load-bearing ranges — rocksdb-js, the encoder/iterator modules whose object identity crosses its boundary, structon, and the optional native addons — are now pinned to the versions the lockfile already resolved. No installed dependency moves; only the allowed resolution narrows. Docker smoke additionally requires the rootmsgpackrand@harperfast/extended-iterablespecs to be byte-equal to rocksdb-js's requirements and rejects a nested copy (#2179). A follow-up aligned the structon pin with the lockfile after it brokenpm cion main (#2196).Also in this release
A report-mode
review-coverageCI check that surfaces cross-model review counts and a staleHuman-Review-Need:footer without blocking (#2183); an integration-test helper refactor (#1904); and non-major dependency updates (#2131, #2189, #2190).Full Changelog: HarperFast/harper@v5.2.2...v5.2.3
honojs/hono (hono)
v4.13.3Compare Source
What's Changed
Full Changelog: honojs/hono@v4.13.2...v4.13.3
oxc-project/oxc (oxlint)
v1.79.0Compare Source
💥 BREAKING CHANGES
8c4552dlinter: [BREAKING] Split react/react-compiler into per-category rules (#25500) (Boshen)🐛 Bug Fixes
228e8e0linter: Resolve inactive React compiler rules (#25830) (Boshen)aa49d86linter: Allow spread rule options in config types (#25675) (ch3rry)36f8451linter/eslint/no-eval: Align indirect default with ESLint (#25656) (camc314)beb724dlinter/eslint/no-unused-vars: Report bare underscore parameters (#25663) (camc314)4004c10linter/eslint/no-irregular-whitespace: Check comments by default (#25660) (camc314)285820elinter/no-large-snapshots: Precompile and document allowed snapshot matchers (#25611) (Mikhail Baev)4df5835linter: Allow capitalized built-in calls (#25516) (Boshen)Configuration
📅 Schedule: (in timezone America/New_York)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR was generated by Mend Renovate. View the repository job log.