Skip to content

chore(deps): update all non-major dependencies - #154

Merged
dawsontoth merged 2 commits into
mainfrom
renovate/all-minor-patch
Aug 24, 2026
Merged

chore(deps): update all non-major dependencies#154
dawsontoth merged 2 commits into
mainfrom
renovate/all-minor-patch

Conversation

@renovate

@renovate renovate Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
@harperfast/skills (source) 1.12.11.12.2 age confidence
@vitest/coverage-v8 (source) 4.1.104.1.11 age confidence
harper (source) 5.2.25.2.4 age confidence
hono (source) 4.13.24.13.3 age confidence
oxlint (source) 1.78.01.79.0 age confidence
vitest (source) 4.1.104.1.11 age confidence

Release Notes

HarperFast/skills (@​harperfast/skills)

v1.12.2

Compare Source

Documentation
vitest-dev/vitest (@​vitest/coverage-v8)

v4.1.11

Compare Source

   🐞 Bug Fixes
    View changes on GitHub
harperfast/harper (harper)

v5.2.4

Compare 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) set context.transaction = null, and the next touch threw Cannot 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() and abort() 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

  • A replicated delete-then-put no longer strips a record's secondary indexes. A replicated delete K; put K transaction — 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)
  • Blind-write transaction bookkeeping corrected. Every write with no preceding read — invalidate, publish, crash-recovery replay, reload markers — installed a native handle without the per-handle reference bookkeeping, leaving the read-transaction count as NaN for each consumer that reads it (commit(), doneReadTxn(), disregardReadTxn(), releaseContext() and abort()). Those transactions are also now visible to the long-transaction monitor. (#​2232)
  • Failed blob saves finish cleaning up before they reject. A failed re-streamable blob save could settle its rejection before PENDING-marker cleanup and blob unlock completed, so a caller attempting immediate recovery could not treat rejection as a lifecycle boundary. Cleanup is now a barrier ahead of rejection. Companion to harper-pro #​732. (#​2228)
  • Asynchronous commit callbacks are awaited. Promise-returning transaction commit callbacks are now awaited by LMDB's optimistic and exclusive paths and by RocksDB before the native transaction commits, so a reload marker's immediate-visibility contract holds on both engines. (#​2208)

Availability

  • The analytics storage metric can no longer OOM the main thread on boot. NODE_STORAGE walked the entire Harper root with an unbounded recursive Promise.all, holding a path, a dirent and a pending stat for 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 through opendir and stats one file at a time. (#​2242, fixes #​2240)
  • storage.debugLongTransactions no longer breaks reads. With the flag on, any search() whose transaction had not opened its own read handle threw TypeError: 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_receiveQueueHighWaterMark is now a registered configuration setting, so the bounded replication receive queue added in harper-pro #​735 can be tuned. (#​2233)
  • harper status reports process uptime, and system_information returns process_uptime in 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.json sync.

Full Changelog: HarperFast/harper@v5.2.3...v5.2.4

v5.2.3

Compare 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.

  • A transient replication save could leave a record referencing a missing, 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 the replication.blobGapReconnectMs config key consumed by harper-pro (#​2177).
  • Superseded blob files were unlinked on a fixed 500 ms timer with nothing checking whether a reader still needed the bytes. Because a blob file is opened lazily by path at 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 that ENOENT lands after response headers are committed, reaching the client as a truncated body while every signal reports success. The delay is now configurable via storage.blobRetention and 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 deploy gains two opt-ins that together let an app be deployed from its git repository instead of an uploaded payload:

  • by_ref=true (or ref=<committish>) resolves the app's GitHub owner/repo and commit from the local working copy (or from GitHub Actions env) and deploys git+https://github.com/<owner>/<repo>.git#<sha>. Everything that could move is resolved client-side to a SHA — including an explicit ref=, locally first and then via git 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=true is a guided, client-side credential provisioning flow — what harper login is for auth, but for deploy tokens. It fetches the cluster's public key, sources a token (a fine-grained PAT, your gh session, or an npm token), seals it locally into an enc: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_component streams instead of base64

package_component returned 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 with ERR_STRING_TOO_LONG once the base64 result exceeded V8's string cap. The operation now streams the archive; project-resolution failures other than ENOENT are 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 install of published harper could 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 root msgpackr and @harperfast/extended-iterable specs 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 broke npm ci on main (#​2196).

Also in this release

A report-mode review-coverage CI check that surfaces cross-model review counts and a stale Human-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.3

Compare Source

What's Changed

  • fix(client): prevent URL corruption when replaceUrlParam contains $ replacement tokens in #​5227
  • fix(etag): copy pending stream bytes in #​5239
  • fix(etag): avoid skipping headers when filtering 304 response headers in #​5234
  • fix(cors): append Origin to Vary header on OPTIONS preflight in #​5235
  • docs(context): add custom headers append option example to Context JSDoc in #​5248
  • fix(trie-router): match suffix wildcard routes in #​5236
  • fix(pattern-router/linear-router): prevent prefix overmatch on wildcard routes in #​5252
  • fix(csrf): exempt OPTIONS request from CSRF validation in #​5250
  • fix(utils/ipaddr): avoid truncation on embedded IPv4 addresses in expand IPv6 in #​5247
  • feat(pretty-json): support structured JSON content-types (+json) in #​5226

Full Changelog: honojs/hono@v4.13.2...v4.13.3

oxc-project/oxc (oxlint)

v1.79.0

Compare Source

💥 BREAKING CHANGES
  • 8c4552d linter: [BREAKING] Split react/react-compiler into per-category rules (#​25500) (Boshen)
🐛 Bug Fixes
  • 228e8e0 linter: Resolve inactive React compiler rules (#​25830) (Boshen)
  • aa49d86 linter: Allow spread rule options in config types (#​25675) (ch3rry)
  • 36f8451 linter/eslint/no-eval: Align indirect default with ESLint (#​25656) (camc314)
  • beb724d linter/eslint/no-unused-vars: Report bare underscore parameters (#​25663) (camc314)
  • 4004c10 linter/eslint/no-irregular-whitespace: Check comments by default (#​25660) (camc314)
  • 285820e linter/no-large-snapshots: Precompile and document allowed snapshot matchers (#​25611) (Mikhail Baev)
  • 4df5835 linter: Allow capitalized built-in calls (#​25516) (Boshen)

Configuration

📅 Schedule: (in timezone America/New_York)

  • Branch creation
    • "before 9am on Monday"
  • Automerge
    • At any time (no schedule defined)

🚦 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.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@dawsontoth dawsontoth left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 alasqlreact-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.

@renovate
renovate Bot force-pushed the renovate/all-minor-patch branch from ec3e03b to 3030123 Compare August 24, 2026 16:06
@renovate
renovate Bot force-pushed the renovate/all-minor-patch branch from 3030123 to 21da00c Compare August 24, 2026 16:07
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>
@dawsontoth

Copy link
Copy Markdown
Contributor

Pushed 8c7564b to fix the lockfile. No version bumps were changed — this is purely the pruned optional subtree being restored.

Regenerated with a single full npm install on top of 21da00c. --package-lock-only does not work here; the subtree is only materialized by a real reify.

The diff is provably additive:

property result
lockfile keys 1402 → 1648 (+246, matching the 246 Missing: errors)
packages removed 0
version changes on pre-existing entries 0
major crossings 0
package.json byte-identical
added entries that are not optional/dev 0

The only two pre-existing entries whose content changed at all are normalize-path and yaml, which each gained "optional": true, "peer": true now that they're also reachable through the restored subtree — same version, same integrity hash, still dev.

Local verification on the pushed tree (Node 24.17.0):

check before after
npm ci ✗ 246 Missing: 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

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 CHANGES_REQUESTED.

Worth fixing upstream rather than by hand each cycle. This is the third time this has hit a repo with a harper dependency (agent#141, vite#37, now this). The trigger is Renovate re-resolving harper itself — the nested alasql@4.17.3 declares optionalDependencies: {"react-native-fs": "^2.20.0"}, and npm writes that field to the lockfile without the 16 packages satisfying it, so npm ci then demands them. A Renovate postUpgradeTasks running one npm install after the bump would close it permanently. Note skipInstalls: false is not a fix (verified and retracted previously; vite has since dropped that override).

Also worth knowing: vite#41 took the identical harper 5.2.2 → 5.2.4 bump in the same batch and was not affected (19 react-native entries retained, npm ci clean), so this is resolution-path-dependent rather than a property of the harper version — the cheap check is the lockfile's react-native key count, not the harper version number.

@dawsontoth
dawsontoth merged commit ef12fa9 into main Aug 24, 2026
5 checks passed
@dawsontoth
dawsontoth deleted the renovate/all-minor-patch branch August 24, 2026 16:13
@github-actions

Copy link
Copy Markdown

🎉 This PR is included in version 0.16.46 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

dawsontoth added a commit that referenced this pull request Sep 1, 2026
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant