chore(deps): update all dependencies to latest - #227
Conversation
Move every dependency to its newest release that the three-day minimum release age admits, regenerate the lockfile from scratch, and drop the five pnpm overrides; the fresh resolution needs none of them and pnpm audit reports no known vulnerabilities. - pnpm 10.34.5 -> 12.6.0: install settings move from package.json to pnpm-workspace.yaml, onlyBuilt/ignoredBuiltDependencies become allowBuilds, and ignoreScripts: false moves there too because pnpm 12 reads no install settings from .npmrc. - vitest 4 -> 5, tsdown 0.22 -> 0.23, oxc-parser 0.147 -> 0.151, @neo4j-labs/agent-memory 0.4 -> 0.5, mem0ai 3.1 -> 3.3, biome 2.5.14 (config migrated). - Admit Eval 0.200 in the peer range (>=0.182.0 <0.201.0); the development pin moves 0.199.0 -> 0.200.1. - Eval 0.201.0, Interface 2.13.1 and Zod 4.6.5 stay out: they require Core 0.10.2 and Zod 4.6.5, while every published Sandbox (0.54.2 through 0.55.3, reached through TCloud 0.6.0) requires Core ^0.9.6 and Zod 4.5.4. The packed-consumer check refused the result with two Core copies. - Publish with npm 12.1.0, the pin agent-sdk and agent-eval publish with. - check-api-surface classifies an export by its declaration: a name declared only as interfaces and type aliases is a type however the build exports it. The record followed the export statement form, so tsdown 0.23 flipped 221 names. With the fix, the tsdown 0.22.14 build of main and this build record identical surfaces; the record diff is 365 value -> type corrections with unchanged shape digests. - Version 17.1.12.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved PR — 4ca2a83a
Blanket team auto-approval is intentional. The merge gates are CI and codex-p1.
No automated review runs on this PR. This approval rests on the rule above alone.
tangletools · auto-approval · reason: blanket_auto_approve · 2026-09-28T08:37:50Z
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4ca2a83a15
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| '@pnpm/exe.win32-arm64': 12.6.0 | ||
| '@pnpm/exe.win32-x64': 12.6.0 | ||
|
|
||
| --- |
There was a problem hiding this comment.
This separator turns pnpm-lock.yaml into a two-document YAML stream: the first document contains only pnpm's executable packages, while the second contains the project's actual dependencies. pnpm's lockfile reader requires a single document; reproducing the workflow's frozen install reports ERR_PNPM_BROKEN_LOCKFILE: expected a single document in the stream, but found more, so both CI and publishing stop at dependency installation. Keep only the project lockfile as one YAML document.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Not applicable to pnpm 12. pnpm 12.6.0, pinned by packageManager, writes this two-document lockfile: the first document records the package manager's own dependencies, and the second records the project. agent-eval's released lockfile on main has the same layout, with its second document starting at line 158. The ERR_PNPM_BROKEN_LOCKFILE reproduction must have used an older pnpm. On this PR, CI's "Install deps" step (pnpm install --frozen-lockfile under pnpm 12.6.0) passed in run 36398431470, and so did a frozen install on GTR.
| "AddSourceOptions": "value bee9a2194b6c", | ||
| "AddSourceTextInput": "value 9619930752c2", | ||
| "AgentMemoryAcquireRunLease": "value 4ff237e19d6d", | ||
| "AdaptiveDecision": "type b5e46c8679f8", |
There was a problem hiding this comment.
Changing this entry and hundreds of peers from value to type is interpreted by compareSurfaces as a narrowing, which requires a major bump for this stable package, while the manifest only moves to 17.1.12. Consequently the pnpm verify:package step in the pull-request CI fails at check:version-bump before the package checks run, even if these are only corrections to previously inaccurate records. Migrate the baseline or otherwise teach the gate about this correction so the committed record does not appear as a breaking public-API change.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in fbf3222. check:version-bump now treats a value -> type move as a record correction only when three things hold:
- the shape digest is unchanged;
check-api-surface --type-declarationslists the name as declared only by interfaces and type aliases in the build;- that build matches HEAD's committed record.
Anything else stays a breaking narrowing. On GTR, none of the 421 value exports is listed, and with dist removed the gate fails closed. pnpm run verify:package now passes and prints: "365 recorded kind(s) corrected from value to type, not narrowed … 1 manifest and 0 export change(s) needing a patch bump, paid for by 17.1.10 -> 17.1.12".
The record took an export's kind from its export statement, so a plain
`export { A }` of an interface was recorded as a value. Deriving the kind from
the declaration corrects 365 entries, and check:version-bump read every one as
a narrowing that needs a major version.
check-api-surface gains --type-declarations, which lists the names whose built
declaration is only interfaces and type aliases and says whether the build
matches the committed record. check:version-bump treats a value -> type move
as a correction only when the shape digest is unchanged, the name is in that
list, and the build matches HEAD's committed record; anything else stays a
breaking narrowing. None of the 421 value exports is listed, and with no build
the gate fails closed.
|
@codex review |
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved PR — fbf32224
Blanket team auto-approval is intentional. The merge gates are CI and codex-p1.
No automated review runs on this PR. This approval rests on the rule above alone.
tangletools · auto-approval · reason: blanket_auto_approve · 2026-09-28T08:56:30Z
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
2 participants
Change
Update every dependency to its newest release that the repository's three-day minimum release age admits, and release as 17.1.12. The lockfile is regenerated from scratch, and all five pnpm overrides are removed. The fresh resolution needs none of them, and
pnpm auditreports no known vulnerabilities.package.jsontopnpm-workspace.yaml.onlyBuiltDependencies/ignoredBuiltDependenciesbecomeallowBuilds.ignoreScripts: falsemoves there too, because pnpm 12 reads no install settings from.npmrc. Without it, a host-wideignoreScriptsskipped the better-sqlite3 build, and the Mem0 OSS integration test failed with "Could not locate the bindings file".>=0.182.0 <0.201.0. The development pin moves from 0.199.0 to 0.200.1, andevalCompatibilitylists 0.200.0 and 0.200.1.Held back, with the reason
Eval 0.201.0, Interface 2.13.1 and Zod 4.6.5 stay out.
Eval 0.201.0 requires Core
^0.10.2and Zod4.6.5, and Interface 2.13.1 pins Zod4.6.5.Every published Sandbox, 0.54.2 through 0.55.3, still requires Core
^0.9.6and Zod4.5.4, and Knowledge reaches Sandbox at runtime through TCloud 0.6.0.With Eval 0.201.0, the packed-consumer check failed: "@tangle-network/agent-core must have one installed copy at 0.10.2", with 0.9.7 also installed under
sandbox/node_modules.Admitting Eval 0.201 therefore waits for a Sandbox release on Core 0.10 and Zod 4.6.5, followed by a TCloud release that takes it.
Other holdbacks:
Those three newer releases are less than three days old, and the repository's release-age policy holds them.
API surface record: 365 kind corrections, no consumer change
check-api-surface.mjsrecorded an export's kind from itsexportstatement form. A plainexport { A }was recorded as a value, even whenAis an interface.tsdown 0.22 exported most declarations that way, and tsdown 0.23 declares them in place. The bump alone therefore flipped 221 names from value to type.
The checker now takes the kind from the declaration: a name declared only as interfaces and type aliases is a type however the build exports it.
Evidence that nothing a consumer sees changed:
58b0795) was built with tsdown 0.22.14, and the fixed checker's record of that build is identical to this branch's tsdown 0.23.0 record.value -> type, all with unchanged shape digests. By declaration in the built.d.tsfiles, 305 are interfaces and 60 are type aliases.check:version-bumpcompares against main's committed record, so it first read the 365 corrections as narrowings that need a major version. It now treats avalue -> typemove as a correction only when three things hold:check-api-surface --type-declarationslists the name as declared only by interfaces and type aliases in the build;Anything else stays a breaking narrowing. None of the 421 value exports is listed, and without a build the gate fails closed.
check-api-surface.mjsandcheck-version-bump.mjsare meant to stay byte-identical with agent-runtime's copies. agent-runtime's copies have already drifted (--recordmode), and they need this change when agent-runtime moves to tsdown 0.23.Proof
Run on GTR with Node 22.23.2 and pnpm 12.6.0, under
systemd-run MemoryMax=12G CPUQuota=400%and nice 19:pnpm install --frozen-lockfilepasses the supply-chain policy check.pnpm lint,pnpm typecheckandpnpm buildpass.vitest runwithAGENT_KNOWLEDGE_RUN_NETWORK_TESTS=1: 93 files and 916 tests pass, 7 skipped.pnpm run verify:packagepasses in full: version bump (365 kind corrections; the manifest change is paid by the patch), skills, path containment,check:api-surface(record current, 997 exports),publint,attwand the packed consumer.node scripts/verify-package.mjspasses with the dev pin (0.200.1) and withAGENT_KNOWLEDGE_EVAL_VERSIONset to each of 0.183.0 through 0.189.0 and 0.200.0.node scripts/verify-official-optimizers.mjspasses with the dev pin, 0.189.0 and 0.200.0.git merge-tree --write-tree origin/main HEADis clean.Release
After merge, and once the
mainpush CI is green, tagv17.1.12. The Publish workflow then publishes through npm trusted publishing.17.1.11, which is on main since #222, was never published, so 17.1.12 also carries its changes. npmlatestis 17.1.10.