Skip to content

chore(deps)(deps-dev): bump the dev-tooling group across 1 directory with 7 updates #1358

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dependabot wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps)(deps-dev): bump the dev-tooling group across 1 directory with 7 updates #1358

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion devnet/edge-update-flow/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,6 @@
"test:devnet": "vitest run --config vitest.config.ts"
},
"devDependencies": {
"vitest": "4.0.18"
"vitest": "4.1.10"
}
}
2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -83,7 +83,7 @@
"devDependencies": {
"@origintrail-official/dkg": "workspace:*",
"@origintrail-official/dkg-core": "workspace:*",
"@types/node": "^22",
"@types/node": "^26",

@otReviewAgent otReviewAgent Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Keep Node types aligned with the repo runtime

What's wrong
The dependency update moves the ambient Node type surface to 26 while the repository still declares Node 22 as the version used by CI and release workflows. That makes the type system less trustworthy because it no longer models the runtime boundary maintainers actually operate against.

Example
A developer can now write code against Node 26-only globals or API shapes and get a clean typecheck, while CI and release workflows still run under Node 22 from .nvmrc. The type boundary no longer documents the runtime the repo actually supports.

Suggested direction
Treat the Node version as a single compatibility boundary. If the project still runs on Node 22, keep @types/node on the Node 22 line. If the goal is to move to Node 26, make that explicit by updating .nvmrc and the workflow/runtime policy in the same change.

For Agents
Look at package.json, packages/evm-module/package.json, and .nvmrc. Keep the runtime support unchanged unless the PR intentionally upgrades it. Either keep @types/node aligned to Node 22, or update the repo runtime policy in .nvmrc/CI together and verify typecheck/build under that runtime.

@otReviewAgent otReviewAgent Jul 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Keep Node type declarations aligned with the repo runtime boundary

What's wrong
This makes the type boundary looser than the runtime boundary. Type declarations are part of the maintainability contract for a TypeScript repo; letting them drift ahead of the Node version the workspace actually runs on encourages accidental use of APIs the project has not declared support for.

Example
A future use of a Node API added after Node 22 would type-check against @types/node@26, but the repo's documented/CI Node line remains 22, so the real runtime boundary is no longer visible from the types.

Suggested direction
Make the Node boundary explicit and single-sourced: either revert the Node typings to the Node 22 line used by .nvmrc, or deliberately move the repo's Node version contract to 26 together with these type bumps.

For Agents
Look at root package.json, packages/evm-module/package.json, and .nvmrc. Preserve the intended runtime support, then either keep @types/node on the Node 22 type line or update .nvmrc/CI/runtime metadata to Node 26 in the same PR. A type-check/build should prove the chosen boundary is consistent.

@otReviewAgent otReviewAgent Jul 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Make the Node runtime/type baseline explicit before widening the typings

What's wrong
Bumping root typings to Node 26 widens the compile-time API surface without showing the corresponding runtime contract. That weakens the type boundary: TypeScript becomes a less reliable signal for what APIs the workspace is actually allowed to use, and the same decision is repeated locally in packages/evm-module.

Example
A developer can now add code that type-checks only because Node 26 typings are available, while a package or script may still be expected to run on Node 20/22. The problem is the unclear boundary: readers cannot tell whether Node 26 APIs are allowed or whether this is only a dev dependency refresh.

Suggested direction
Declare the supported Node baseline centrally, then align @types/node to that policy. If the project now intentionally requires Node 26 APIs, make that visible with engines and consistent package metadata; otherwise keep typings on the supported runtime major.

Confidence note
This is a maintainability/type-boundary concern, not a claim that current code already uses a Node 26-only API. The repo context shown here does not expose a central runtime engine declaration that would make the new type baseline explicit.

For Agents
Inspect the root package policy and packages/evm-module/package.json. Preserve the intended type upgrade, but declare the supported Node runtime baseline in one canonical place and align @types/node to that baseline through the same dependency-management mechanism used for shared tooling. Add a typecheck/install verification step after regenerating the lockfile.

@otReviewAgent otReviewAgent Jul 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Keep Node typings aligned with the repo's runtime policy

What's wrong
The PR upgrades the type surface to Node 26 while the repository still advertises and runs against Node 22. That weakens the platform contract: types stop being a reliable description of the runtime, and future code can silently depend on APIs the canonical runtime does not provide.

Example
A future change can import or call a Node 26-only API and still typecheck locally, while the repo's canonical runtime/build lane remains Node 22. That makes the TypeScript boundary describe a different platform than the one contributors and CI are actually using.

Suggested direction
Treat this as a boundary cleanup, not just a package bump. Either keep @types/node on the Node 22 line, or make Node 26 the explicit repo runtime by updating .nvmrc, CI, release tooling, and package engines in the same change.

For Agents
Look at root package.json, packages/evm-module/package.json, .nvmrc, and workflows that read .nvmrc. Preserve the intended runtime, but make the Node version contract single-source: either keep typings on Node 22, or intentionally move the runtime policy to Node 26 by updating .nvmrc/CI/package engines together. Add a small compile check that proves the selected @types/node version matches the supported Node runtime.

@otReviewAgent otReviewAgent Jul 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Keep Node ambient types aligned with the repo runtime contract

What's wrong
The PR upgrades the ambient Node types to 26 while the repository still signals Node 22 as the workspace runtime. That makes the type system less useful as a boundary: it can now bless APIs that are not guaranteed by the runtime this repo tells contributors to use.

Example
A future change can compile after using a Node 26-only global/API because @types/node@26 exposes it, even though the workspace still advertises Node 22 via .nvmrc. The type boundary no longer models the supported runtime.

Suggested direction
Treat @types/node as part of the runtime contract, not just a floating dev dependency. If the repo still supports or pins Node 22, keep the Node 22 types; if Node 26 is intended, make that explicit in .nvmrc/engines/CI and update all related comments/docs together.

For Agents
Check the root runtime policy (.nvmrc, CI images, docs) before changing Node ambient types. Either bump the runtime contract everywhere to Node 26, or keep @types/node on the supported Node major. Verify with a typecheck on the intended Node lane.

@otReviewAgent otReviewAgent Jul 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Make the Node runtime boundary explicit before widening Node types

What's wrong
The diff widens the workspace’s Node type contract without also declaring the runtime contract that those types are meant to represent. That creates a blurry boundary where code can start depending on newer Node APIs because the types allow them, while the repo gives maintainers no manifest-level answer for what Node versions are actually supported.

Example
After this change, TypeScript can accept Node 26 APIs in shared scripts or package code even though the workspace does not state that developers, CI, or published consumers must run that runtime family.

Suggested direction
Add an explicit root engines.node contract, and mirror it where published packages need their own runtime boundary, or avoid moving to Node 26 types until the runtime support policy is deliberately raised.

Confidence note
This is a maintainability boundary concern rather than a claim that the current install fails; it depends on the project’s intended supported Node versions.

For Agents
Inspect the root package metadata and package-level publish/runtime expectations. Either add an explicit engines.node policy that matches the upgraded toolchain/runtime contract, or keep @types/node aligned to the actual supported runtime. Verify package builds still use the intended Node type boundary.

@otReviewAgent otReviewAgent Jul 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Keep Node type declarations aligned with the repo runtime

What's wrong
The PR upgrades the type surface to Node 26 while the repo still declares Node 22 as the development/runtime baseline. That makes the TypeScript boundary misleading: reviewers and contributors can no longer tell from the canonical config which Node APIs are actually safe to use. The same pattern recurs in packages/evm-module/package.json line 47.

Example
A contributor on the documented Node 22 runtime can now write code that type-checks against Node 26-only globals or API shapes because the workspace type surface no longer matches the runtime baseline.

Suggested direction
Treat the Node version as one workspace-level contract. Either leave @types/node on 22 here and in evm-module, or move the whole repo runtime policy to the version whose types are being adopted.

For Agents
Keep the runtime and type boundary aligned. Check .nvmrc, README prerequisites, CI setup-node usage, root package.json, and packages/evm-module/package.json. Either keep @types/node on the Node 22 line or update the repo's runtime policy/docs/CI together. A typecheck on the documented runtime should prove the boundary is coherent.

@otReviewAgent otReviewAgent Jul 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Node 26 typings no longer match the Node 22 runtime contract

What's wrong
The repository still advertises and runs against Node 22, but the type surface now represents Node 26. That weakens the type checker as a runtime compatibility gate: code can compile against APIs or signatures that are not available in the supported runtime.

Example
A future change could use an API that exists in @types/node@26 but is absent from the repository's Node 22 runtime. TypeScript would accept it, CI would still install Node 22 from .nvmrc, and the released CLI/node code could fail at runtime when that path executes.

Suggested direction
Keep @types/node on the same major version as the supported Node runtime, or explicitly raise the repository runtime version everywhere that consumes .nvmrc.

Confidence note
The diff does not add code that already calls a Node 26-only API, so this is an integration contract risk rather than an observed runtime failure.

For Agents
Align Node typings with the actual supported runtime. Check root package.json, packages/evm-module/package.json, .nvmrc, and CI setup-node usage. Either keep @types/node on the Node 22 line or update the runtime contract and CI to Node 26. Add a small compile/runtime guard if a Node-version-specific API is intentionally introduced.

Make the Node runtime boundary explicit with the Node type bump

What's wrong
The PR moves the ambient Node type surface to Node 26 without declaring the corresponding runtime floor. That makes the type boundary looser than the runtime contract and leaves future contributors guessing which Node APIs are safe to use. This is a maintainability problem because the repository policy lives in incidental dependency choices rather than in package metadata.

Example
After this bump, a new helper can type-check against Node 26-only APIs because the ambient Node types expose them. Nothing in the package metadata tells maintainers or consumers whether running under Node 20 or Node 22 is still supported.

Suggested direction
Couple the @types/node major bump with an explicit Node support policy, preferably in engines.node for the root and any published workspaces. If the repo still supports an older Node major, keep the Node typings on that minimum supported major instead of widening the ambient API surface to 26.

Confidence note
If the project intentionally now requires Node 26 or a newer Node floor, the same concern still applies: that policy should be declared in package metadata rather than only implied by typings and tool dependencies.

For Agents
Inspect CI/runtime requirements and published package support policy. Either add explicit engines.node entries at the root and publishable packages that match the intended Node floor, or keep @types/node aligned to the minimum supported runtime major. Preserve existing build/test behavior and verify package metadata checks still pass.

@otReviewAgent otReviewAgent Jul 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Keep Node type definitions aligned with the workspace runtime boundary

What's wrong
@types/node is part of the TypeScript boundary for scripts and packages. Moving it to Node 26 while the workspace still advertises Node 22 makes the supported runtime implicit and easier to violate accidentally.

Example
A later script can start using a Node 26-only API and still typecheck because the workspace types expose it, even though contributors and CI are guided to Node 22 by .nvmrc.

Suggested direction
Either keep @types/node on the Node major the repo actually runs, or make the Node runtime upgrade explicit in the same PR. The maintainable shape is one clear Node baseline, not type definitions that silently move ahead of the runtime contract.

Confidence note
This assumes the repository still intends .nvmrc value 22 to describe the supported local/CI runtime; I did not see an engines field overriding that in the changed manifests.

For Agents
Check the intended Node runtime baseline. If it remains Node 22, keep @types/node on the matching major across root and package manifests. If the PR intentionally raises the runtime floor, update .nvmrc and any package engines policy in the same change so the type boundary and runtime boundary stay aligned.

"@vitest/coverage-v8": "^4.0.18",
"esbench": "^0.8.1",
"knip": "^6.6.1",
Expand Down
2 changes: 1 addition & 1 deletion packages/evm-module/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@
"@typechain/ethers-v6": "^0.5.1",
"@typechain/hardhat": "^9.1.0",
"@types/chai": "^4.3.20",
"@types/node": "^22.10.2",
"@types/node": "^26.1.1",
"assertion-tools": "^8.0.3",
"chai": "^4.5.0",
"ethers": "^6.13.4",
Expand Down
2 changes: 1 addition & 1 deletion packages/graph-viz/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,7 +75,7 @@
"three": "^0.184.0",
"tsup": "^8.4.0",
"typescript": "^5.7.0",
"vite": "^6.4.2",
"vite": "^8.1.4",
"vitest": "^4.0.18"
},
"keywords": [
Expand Down
4 changes: 2 additions & 2 deletions packages/network-sim/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,10 +17,10 @@
"devDependencies": {
"@types/react": "^19.0.0",
"@types/react-dom": "^19.0.0",
"@vitejs/plugin-react": "^4.4.0",
"@vitejs/plugin-react": "^6.0.3",

@otReviewAgent otReviewAgent Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Centralize the workspace toolchain versions instead of adding more divergent specifiers

What's wrong
This PR upgrades the same build/test toolchain in multiple package manifests, but it leaves each workspace expressing the versions differently. That is not just lockfile churn: it increases the number of places future maintainers must remember to update and makes it harder to tell whether a workspace intentionally differs or simply drifted.

Example
A future Vite or Vitest bump now has to rediscover several independent specifier styles: ^8.1.0, ^8, exact 4.1.9, and existing ^4.0.18 ranges. That makes the lockfile the only place where the actual toolchain version is coherent.

Suggested direction
Introduce a single dependency-version policy for the shared toolchain, then reference it from each workspace instead of hand-maintaining local semver ranges.

Confidence note
The repo does not currently use pnpm catalogs, so the exact centralization mechanism is a policy choice; the duplicated and divergent version specifiers are visible in the changed manifests.

For Agents
Look at pnpm-workspace.yaml, root package.json, and the changed package manifests. Preserve the selected resolved versions, but move shared build/test tool versions such as vite, @vitejs/plugin-react, vitest, @vitest/coverage-v8, and @types/node behind one workspace-level policy, preferably pnpm catalogs if acceptable for this repo. Regenerate pnpm-lock.yaml and verify the lockfile still resolves the same toolchain versions.

@otReviewAgent otReviewAgent Jul 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Centralize the shared toolchain versions instead of adding more per-package literals

What's wrong
This PR updates workspace-wide build/test tooling by editing individual package manifests directly. In a monorepo, that makes dependency policy harder to audit because the intended Vite/React plugin/Vitest/Node-types version is no longer expressed once; it is inferred from several duplicated literals with different specificity. The implementation works as dependency metadata, but structurally it increases drift risk and makes future toolchain upgrades noisier than necessary.

Example
A future Vite/plugin/Vitest maintenance bump now has to rediscover and edit several package manifests with slightly different range styles (^8, ^8.1.3, ^6, ^6.0.3, exact 4.1.10). That keeps the lockfile coherent today, but leaves the workspace dependency policy encoded as scattered literals rather than one obvious source of truth.

Suggested direction
Use a pnpm catalog in pnpm-workspace.yaml for the shared build/test toolchain, then reference it from package manifests with catalog:. That would make this upgrade a single policy change instead of a set of hand-synchronized manifest edits, and it would remove the inconsistent range styles introduced here.

For Agents
Look at the package manifests touched by this PR plus pnpm-workspace.yaml. Preserve the resolved versions, but move shared toolchain dependencies such as Vite, @vitejs/plugin-react, Vitest, coverage, and Node types behind a central pnpm catalog or another existing workspace-level version policy. Prove the manifest change with pnpm install --lockfile-only and a representative filtered install/build.

@otReviewAgent otReviewAgent Jul 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Upgrade the frontend toolchain as a coherent unit

What's wrong
The PR performs a major Vite/plugin-react bump but leaves coupled test-tool declarations on the old 4.0.x baseline. That creates dependency drift in the package boundary: package.json no longer tells readers which test/build stack this package is meant to run, and future updates can easily move one part without the others. The same root cause recurs at packages/graph-viz/package.json line 78 and packages/node-ui/package.json line 63.

Example
A future maintainer reading packages/network-sim/package.json sees Vite 8 but Vitest/Coverage 4.0.18, while the lockfile actually installs Vitest/Coverage 4.1.10. The dependency graph's intended baseline is split between manifests and lockfile resolution.

Suggested direction
Make the manifests describe the same toolchain baseline the lockfile installs. The cleaner move is a shared workspace catalog or a synchronized bump of Vite, @vitejs/plugin-react, Vitest, and @vitest/coverage-v8 across the affected packages, instead of relying on the lockfile to paper over stale direct ranges.

Confidence note
This is based on the manifests and lockfile diff; it does not require assuming the dependency versions are behaviorally broken.

For Agents
Review the Vite/Vitest/Coverage/React plugin versions as one frontend toolchain. Update the direct manifest ranges together, or introduce a pnpm catalog/shared dependency policy so package.json files declare the intended baseline. Preserve the current resolved versions, then run install/typecheck/tests for graph-viz, network-sim, and node-ui.

"@vitest/coverage-v8": "^4.0.18",
"typescript": "^5.7.0",
"vite": "^6.1.0",
"vite": "^8.1.4",
"vitest": "^4.0.18"
}
}
4 changes: 2 additions & 2 deletions packages/node-ui/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,7 @@
"@types/react": "^19",
"@types/react-dom": "^19",
"@types/three": "^0.183.1",
"@vitejs/plugin-react": "^4",
"@vitejs/plugin-react": "^6",

@otReviewAgent otReviewAgent Jul 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Centralize the toolchain version bumps instead of adding more per-package drift

What's wrong
This PR upgrades shared toolchain packages by editing individual workspace manifests with different range styles and leaves many related manifests on older-looking ranges while the lockfile resolves them to newer versions. That makes the dependency model less legible: the source of truth becomes split between leaf manifests, root overrides, and the generated lockfile. The cleaner structure is to make the intended toolchain baseline explicit once, then have workspaces consume it consistently.

Example
A future pnpm update can now move node-ui to any Vite 8.x, keep network-sim on a different floor, and leave most Vitest manifests advertising the old ^4.0.18 baseline even though the lockfile currently resolved 4.1.10. Maintainers have to read the lockfile to infer the intended toolchain version.

Suggested direction
Use one canonical version declaration for shared dev tooling, preferably a pnpm catalog given this repo already standardizes on pnpm 10. At minimum, make the manifest ranges consistent across all workspaces touched by this lockfile refresh and align the existing Vite override/dependency policy with the Vite 8 baseline.

For Agents
Look at the shared dev-tool dependencies in package.json, packages//package.json, and devnet//package.json. Preserve the intended upgrades to Node types, Vite, plugin-react, and Vitest, but move their versions into a single policy surface such as pnpm catalogs or consistent workspace-wide ranges, then update affected manifests to reference that policy. Verify with pnpm install --lockfile-only and a recursive dependency listing that only the intended versions resolve.

@otReviewAgent otReviewAgent Jul 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Vite 8 raises the required Node version beyond the repo's Node 22 contract

What's wrong
The changed Vite dependency now requires Node ^20.19.0 || >=22.12.0, but the workspace still advertises the broad Node 22 line via .nvmrc. That can make supported Node 22.x environments below 22.12 fail when they build or run the UI tooling.

Example
On a developer or release environment using Node 22.11 from the existing .nvmrc line, pnpm --filter @origintrail-official/dkg-node-ui run build:ui will invoke Vite 8, whose own engine range excludes that runtime. Expected: the repo's Node 22 setup remains buildable, or the repo explicitly pins a compatible Node version such as 22.12+.

Suggested direction
Update the repo's Node version contract to a concrete compatible version, or avoid the Vite 8/plugin-react 6 upgrade until the supported Node floor is raised.

Confidence note
This depends on whether the project still intends to support the whole Node 22 line implied by .nvmrc rather than only current/latest Node 22 releases.

For Agents
Look at the Vite 8 upgrades in packages/node-ui, packages/network-sim, and packages/graph-viz, plus the root .nvmrc and workflows. Either pin the repo runtime to a Vite-compatible Node version or keep Vite/plugin-react on versions compatible with the current Node contract. Prove the fix by running install and the UI build under the Node version advertised by .nvmrc.

Centralize the shared toolchain version policy instead of scattering new ranges

What's wrong
The PR updates the same toolchain family across several workspace packages, but each manifest now expresses the version intent differently. That is maintainability drift: reviewers and future dependency PRs must reason about lockfile side effects and local range choices instead of a single workspace-level toolchain policy.

Example
The next Vite or Vitest upgrade has to infer intent from several package manifests plus pnpm-lock.yaml: is the project policy ^8, ^8.1.3, or the exact locked version? That ambiguity is small today, but it scales poorly as more packages grow their own toolchain pins.

Suggested direction
Use one canonical version policy for shared build/test tooling, for example pnpm catalogs or another repo-standard dependency policy mechanism, and have package manifests reference it consistently. This would let the PR say "the workspace is on Vite 8.1.3 / plugin-react 6.0.3 / Vitest 4.1.10" once instead of encoding that policy slightly differently in each package.

For Agents
Review all changed package.json files for Vite, @vitejs/plugin-react, Vitest, @vitest/coverage-v8, and @types/node. Preserve resolved versions, but move the shared toolchain versions into one policy location, such as pnpm catalogs or a documented root-level version block, then reference that from package manifests. Verify pnpm install --frozen-lockfile keeps the same resolved graph.

Vite 8 production bundle path is not validated

What's wrong
This PR changes the toolchain that produces the shipped Node UI static assets, but the normal PR validation path appears to skip that production bundle. Existing Vitest and Playwright coverage can pass while the release-facing vite build path is broken.

Example
A Vite 8 production-build regression in pnpm --filter @origintrail-official/dkg-node-ui build:ui would not be caught by the existing PR build, because CI restores the package build artifact and never builds dist-ui on the changed Vite version.

Suggested direction
Add a targeted build smoke for the Vite-backed UI bundle, or provide explicit validation evidence that the bundle still builds under Vite 8.

For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the existing fast package-build/test lanes, but add targeted validation for the changed Vite production path, such as a CI step or documented PR evidence running pnpm --filter @origintrail-official/dkg-node-ui build:ui; consider including packages/network-sim build and packages/graph-viz demo:build if those Vite 8 paths are intended to be covered too.

@otReviewAgent otReviewAgent Jul 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔴 Bug: Vite 8 narrows the supported Node 22 range below the documented contract

What's wrong
This dependency bump makes the runtime UI build depend on Vite 8, but Vite 8 requires Node ^20.19.0 or >=22.12.0. The repo still tells users and CI to use generic Node 22+, so Node 22.0 through 22.11 remain documented as valid even though the changed build toolchain no longer supports them. That can block runtime/package builds and auto-update style source builds for users on an otherwise documented Node 22 installation.

Example
A user following the README on Node 22.10.0 is still on "Node.js 22+", but pnpm --filter @origintrail-official/dkg-node-ui run build:ui now invokes Vite 8, whose supported engine range starts at Node 22.12.0. Expected: documented Node 22+ users can build the runtime UI. Current: supported-but-older Node 22 installations fall outside the toolchain's engine contract and can fail at install/build time.

Suggested direction
Align the dependency bump with the supported Node contract: downgrade/hold Vite for Node 22.0+ compatibility, or update .nvmrc, README prerequisites, package engines, and CI/publish setup to require a concrete Node version that satisfies Vite 8.

Confidence note
I did not run the build under an older Node 22.x binary in this read-only sandbox; this is based on the new dependency engine metadata in the lockfile and the repo's documented Node 22+ support contract.

For Agents
Check the Vite/plugin-react bumps in packages/node-ui, packages/graph-viz, and packages/network-sim plus pnpm-lock.yaml. Either keep the Vite toolchain on a version compatible with all documented Node 22.x releases, or change the public/CI contract to a concrete minimum like >=22.12.0 and add an engines/preflight check that proves pnpm build:runtime fails fast with a clear message on older 22.x.

Centralize the Vite toolchain version instead of scattering mixed ranges

What's wrong
The PR updates the frontend toolchain in three package manifests with slightly different range contracts and leaves related root dependency policy on the old Vite major. That makes the toolchain ownership blurry and increases future lockfile churn.

Example
A later lockfile refresh can legally resolve node-ui to a newer Vite 8 minor than network-sim/graph-viz, even though these packages are supposed to share the same frontend toolchain generation.

Suggested direction
Use one workspace-level source of truth for Vite/plugin-react versions, or at least use the same version range shape across the packages touched here. Also revisit the root Vite override so dependency policy does not point at the previous major line while direct deps move to Vite 8.

Confidence note
This is based on manifest structure and lockfile resolution only; there may be an external dependency-management policy not visible in the diff.

For Agents
Review the workspace dependency policy for Vite and React plugin versions. Keep behavior unchanged, but express the Vite 8 toolchain through one consistent range or a shared pnpm catalog/override, and update obsolete Vite 7 policy entries if they are no longer canonical.

Node UI production Vite build is not validated in PR CI

What's wrong
This dependency change affects the production dashboard bundle, but the existing PR checks appear to skip that exact vite build path. The PR still gets coverage for package builds, Vitest, and the Playwright dev server, but not for the static dist-ui artifact that release/publish later produces.

Example
A minimal validation that currently is not represented in PR CI would be pnpm --filter @origintrail-official/dkg-node-ui run build:ui; this is the command most directly affected by the Vite 8 upgrade.

Suggested direction
Add a targeted CI check or documented validation evidence for @origintrail-official/dkg-node-ui's build:ui path when bumping Vite/plugin-react, ideally without replacing the existing package-build optimization.

For Agents
Look at packages/node-ui/package.json, scripts/build.mjs, and .github/workflows/ci.yml. Preserve the existing fast build:packages behavior, but add a PR-visible validation step or targeted job that runs the Node UI production bundle command after the Vite/plugin-react upgrade, and make it fail on build errors.

@otReviewAgent otReviewAgent Jul 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Centralize the shared toolchain version policy instead of encoding divergent ranges

What's wrong
This PR is a cross-workspace toolchain upgrade, but the changed manifests encode the same dependency family with different range styles and floors. That makes package.json stop being a clear source of truth: readers have to infer the real policy from the lockfile, and future dependency updates can drift per package for reasons unrelated to the package itself.

Example
A future pnpm update vite or package-local install can move node-ui to a newer Vite 8 minor while graph-viz/network-sim stay bounded by a different floor; edge-update-flow is the only devnet package that cannot float within Vitest 4. The lockfile hides that today, but the manifests now encode several different policies for the same shared toolchain.

Suggested direction
Use a single workspace-level version source for these toolchain dependencies, such as pnpm catalogs, then reference it from each package. If catalogs are too large a change for this PR, align the changed ranges consistently so the manifests express one upgrade policy instead of several package-local variants.

For Agents
Look at root package.json, pnpm-workspace.yaml, and the changed package manifests. Preserve the intended Vite/Vitest/@types/node upgrades, but move shared toolchain versions into one policy: preferably pnpm catalogs for vite, @vitejs/plugin-react, vitest, @vitest/coverage-v8, and @types/node, or at least align all manifest ranges exactly. Verify with pnpm install --lockfile-only that the lockfile remains stable.

The Vite 8 production UI build path is not covered by the existing validation

What's wrong
This PR changes the major Vite and React plugin versions used to build the published Node UI bundle, but the repository’s CI path shown in the workflow comments deliberately skips that bundle and the browser e2e lane uses the dev server. That leaves the riskiest changed behavior for this dependency bump unverified.

Example
A regression that only appears during vite build, such as an asset transform, chunking, or production-only plugin behavior change from Vite 8 / plugin-react 6, can still pass the current CI because pnpm run build:packages skips dist-ui and the e2e job runs the dev server.

Suggested direction
Add or document a targeted production-bundle validation for Node UI as part of this dependency upgrade, rather than relying only on package builds and dev-server e2e coverage.

For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the existing fast shared build behavior if needed, but add validation for the changed production Vite path, for example a targeted CI step or required local evidence running pnpm --filter @origintrail-official/dkg-node-ui run build:ui / pnpm build:runtime. The proof should fail if Vite 8 cannot produce the Node UI production bundle.

"@vitest/coverage-v8": "^4.0.18",
"cross-env": "^10.1.0",
"happy-dom": "20.8.9",
Expand All @@ -60,7 +60,7 @@
"recharts": "^2",
"three": "^0.184.0",
"typescript": "^5.7",
"vite": "^6",
"vite": "^8",

@otReviewAgent otReviewAgent Jun 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: The Vite 8 upgrade is not validated against the Node UI production bundle

What's wrong
This dependency bump changes the toolchain for the published Node UI bundle, but the normal PR workflow intentionally avoids that bundle build. Existing tests exercise Vitest and the Vite dev server, which does not prove the production vite build path still works after a major Vite/plugin-react upgrade.

Example
A Vite 8 production-only break, such as changed asset handling or build-time plugin behavior, could still pass the current PR CI because node-ui unit tests and Playwright run without executing pnpm --filter @origintrail-official/dkg-node-ui run build:ui.

Suggested direction
Add CI or PR validation that runs the affected production bundle command before merging this dependency upgrade.

Confidence note
I could verify the CI definitions in the workspace, but not PR run results. The finding is about missing PR-level validation in the checked-in workflow.

For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the existing fast package build, but add a focused PR validation step for the Vite production bundle, for example pnpm --filter @origintrail-official/dkg-node-ui run build:ui, or otherwise document/link evidence that the PR ran the release pnpm build path.

@otReviewAgent otReviewAgent Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: The Vite 8 upgrade is not validated on the production node-ui bundle path

What's wrong
This PR upgrades the toolchain that builds the shipped Node UI static bundle, but the visible validation covers tests and dev-server e2e rather than the production vite build artifact. That leaves a user-facing release path unverified for a major bundler/plugin upgrade.

Example
A regression where Vite 8 changes production bundling, asset paths, or plugin-react behavior could make pnpm --filter @origintrail-official/dkg-node-ui run build:ui fail or emit a broken dist-ui/, while the current PR checks still pass because they test node-ui Vitest and Playwright dev-server paths only.

Suggested direction
Add CI or documented validation evidence that runs the node-ui production Vite build after the Vite/plugin-react upgrade, ideally as a targeted build:ui check so the release artifact path is covered.

For Agents
Look at packages/node-ui/package.json and CI. Preserve the existing fast build:packages path if needed, but add explicit validation for the changed production bundle path, such as a PR check running pnpm --filter @origintrail-official/dkg-node-ui run build:ui or root pnpm build for dependency-upgrade PRs. The proof should fail if Vite/plugin-react cannot produce dist-ui.

@otReviewAgent otReviewAgent Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Vite 8 production UI bundle is not verified on PRs

What's wrong
This dependency bump changes the tool that creates the published Node UI static bundle, but the PR validation paths I found do not exercise that production bundle. That leaves release-facing breakage possible even when the PR CI is green.

Example
A regression where pnpm --filter @origintrail-official/dkg-node-ui run build:ui fails under Vite 8 would not be caught by the existing PR checks: node-ui unit tests and Playwright e2e exercise the Vite dev server, while the shared CI build intentionally omits the production dist-ui bundle.

Suggested direction
Add a focused PR validation step for the Node UI production bundle, or otherwise require documented evidence that build:ui passes with Vite 8 before merging this dependency bump.

For Agents
Look at packages/node-ui/package.json, scripts/build.mjs, and .github/workflows/ci.yml. Preserve the fast package build if needed, but add validation for the changed production Vite bundle path, for example a focused CI step or required evidence running pnpm --filter @origintrail-official/dkg-node-ui run build:ui after the Vite upgrade.

@otReviewAgent otReviewAgent Jun 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Centralize the frontend toolchain versions

Why it matters
This PR updates the same frontend toolchain across multiple packages but keeps the version policy scattered, with node-ui using broader major ranges than network-sim/graph-viz. The lockfile currently pins one resolution, but the manifests do not give maintainers a single place to understand or update the intended toolchain version.

Suggestion
Consider moving shared build/test tool versions such as vite, @vitejs/plugin-react, vitest, and @vitest/coverage-v8 into a pnpm catalog or another single repo-owned version policy, then reference that from the package manifests. That would make future toolchain bumps one deliberate edit instead of several package-local range changes.

The Vite 8 bump is not validated against the node-ui production build in PR CI

What's wrong
This dependency bump changes the toolchain used for the shipped node-ui bundle, but the visible PR validation paths exercise TypeScript build, Vitest, and Vite dev-server E2E rather than the production build:ui command. That leaves a real gap for production-only Vite failures.

Example
A Vite 8 regression that only appears during production bundling, such as asset emission, CSS processing, or chunk generation, could make pnpm --filter @origintrail-official/dkg-node-ui build:ui fail while the existing PR build, unit tests, and Playwright dev-server E2E remain green.

Suggested direction
Add a CI step or documented validation evidence for the node-ui production vite build path when upgrading Vite/plugin-react.

Confidence note
I inferred this from the checked-in scripts and workflow configuration; I did not run the CI jobs in this read-only review environment.

For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the existing unit and E2E lanes, but add PR validation for pnpm --filter @origintrail-official/dkg-node-ui build:ui or run the root build path that includes it; the check should fail if Vite 8 cannot produce the production UI bundle.

@otReviewAgent otReviewAgent Jul 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Centralize the frontend toolchain version policy

Why it matters
The PR updates the same frontend build toolchain in multiple workspace manifests, but leaves slightly different version ranges. The lockfile currently resolves one version, yet future installs or follow-up bumps can drift by package, making toolchain upgrades harder to audit.

Suggestion
Consider introducing a pnpm catalog for shared dev-tool versions, or at least use identical specifier text for Vite and the React plugin across the affected packages. That keeps the update as one policy decision instead of three subtly different local choices.

The node-ui Vite 8 production build is not covered by PR validation

What's wrong
This dependency bump changes the tool that produces the published/runtime node-ui browser bundle, but the existing PR checks appear to exercise only TypeScript compilation, unit tests, and Vite’s dev server. That leaves the release-facing vite build path unverified for a major Vite/plugin-react upgrade.

Example
A Vite 8 production-only regression, such as a changed build-time asset transform or unsupported production option in packages/node-ui/vite.config.ts, could make pnpm --filter @origintrail-official/dkg-node-ui build:ui fail while the current PR checks still pass because they run tsc, unit tests, and vite dev server.

Suggested direction
Add a CI step or required validation command for the node-ui production bundle, not just the dev server and TypeScript build, before accepting the Vite major upgrade.

Confidence note
I did not run CI in this read-only environment; this is based on the package scripts and workflow commands in the repository.

For Agents
Look at packages/node-ui/package.json, packages/node-ui/vite.config.ts, and .github/workflows/ci.yml. Add PR validation that runs pnpm --filter @origintrail-official/dkg-node-ui build:ui or include node-ui build:ui in the CI build graph when Vite/plugin-react are bumped. The proof should be that the production UI bundle succeeds under the upgraded Vite version.

@otReviewAgent otReviewAgent Jul 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Node UI’s Vite 8 production build is not verified

What's wrong
This PR upgrades the node-ui Vite toolchain, but the PR validation path does not appear to run the production vite build for dist-ui. The existing e2e coverage is useful, but it starts the Vite dev server, which does not verify production bundling behavior. That leaves the most deployment-relevant behavior changed by this dependency bump untested.

Example
A Vite 8/Rolldown production-only regression in packages/node-ui/vite.config.ts or a chunk/CSS minification failure would be caught by pnpm --filter @origintrail-official/dkg-node-ui build:ui, but the current PR validation can still pass because CI builds only the node-ui TypeScript package and runs e2e through the dev server.

Suggested direction
Add an explicit CI or documented validation step that runs the node-ui production bundle after the Vite/plugin-react upgrade, ideally pnpm --filter @origintrail-official/dkg-node-ui build:ui.

For Agents
Look at packages/node-ui/package.json, turbo.json, and .github/workflows/ci.yml. Add PR validation for pnpm --filter @origintrail-official/dkg-node-ui build:ui or include build:full/build:ui in the relevant CI path, preserving the existing dev-server Playwright coverage. The proof should fail if Vite 8 cannot create the production dist-ui bundle.

@otReviewAgent otReviewAgent Jul 6, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Node UI production Vite build is not validated after the major upgrade

What's wrong
This diff changes the toolchain that produces the shipped Node UI static bundle, but the existing PR validation path intentionally skips that bundle and the e2e lane runs the dev server. That leaves the changed production build path unverified even though it is user-facing release output.

Example
A Vite 8 production-only regression in packages/node-ui/vite.config.ts, asset base handling, or dist-ui emission could still pass the current PR lanes because node-ui unit tests and Playwright e2e do not run pnpm --filter @origintrail-official/dkg-node-ui run build:ui.

Suggested direction
Add or require a focused validation step for the Node UI production bundle when bumping Vite/plugin-react, rather than relying only on Vitest and Playwright dev-server coverage.

For Agents
Look at packages/node-ui/package.json and .github/workflows/ci.yml. Preserve the fast shared build if needed, but add explicit validation for the changed production bundle path, such as a targeted CI step or documented required check that runs pnpm --filter @origintrail-official/dkg-node-ui run build:ui, possibly gated to package/lockfile changes. The test should prove the Vite 8 + plugin-react 6 production bundle still builds and emits dist-ui.

@otReviewAgent otReviewAgent Jul 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Vite 8 upgrade lacks a production bundle check

What's wrong
The dependency change alters the production UI bundler, but the existing validation path does not build the production dist-ui bundle on pull requests. That leaves the release/static UI path unverified for this major Vite/plugin upgrade.

Example
A Vite 8 production-only regression, such as a build-time plugin/config incompatibility or bad generated /ui/ asset path, could make pnpm --filter @origintrail-official/dkg-node-ui build:ui fail or emit a broken dist-ui bundle while the current PR gates still pass because they exercise Vitest and the Vite dev server.

Suggested direction
Add CI coverage for the node-ui production Vite build, and consider serving the built dist-ui in a lightweight smoke test so the upgraded bundler path is actually verified.

For Agents
Check packages/node-ui/package.json, root build scripts, and .github/workflows/ci.yml. Add a PR validation step for pnpm --filter @origintrail-official/dkg-node-ui build:ui or build:full; ideally add a small smoke that serves dist-ui and loads /ui/ so the production Vite 8 output is covered while preserving the existing dev-server e2e lane.

@otReviewAgent otReviewAgent Jul 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Vite 8 production UI build is not validated

What's wrong
This PR upgrades the build tool used for the published Node UI static bundle, but the visible validation only exercises tests and the Vite dev server. The production bundle path can break differently from dev-server mode, so the dependency bump is not adequately verified for the artifact users receive.

Example
A Vite 8 production-only regression in asset URLs, base: '/ui/', or bundle generation could still pass CI because pnpm --filter @origintrail-official/dkg-node-ui test and the Playwright dev-server lane never run pnpm --filter @origintrail-official/dkg-node-ui build:ui.

Suggested direction
Add CI or PR evidence that runs the Node UI production Vite build after this major Vite/plugin upgrade, ideally scoped to packages/node-ui so it does not undo the rest of the CI optimization.

For Agents
Look at packages/node-ui/package.json and CI build jobs. Preserve the existing fast package build, but add validation for the Vite 8 production bundle, such as a targeted pnpm --filter @origintrail-official/dkg-node-ui build:ui smoke job or including build:full/build:runtime in the dependency-upgrade validation path. The proof should fail if vite build cannot emit dist-ui with the configured /ui/ base.

@otReviewAgent otReviewAgent Jul 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟡 Issue: Centralize shared toolchain versions instead of adding per-package range drift

What's wrong
The PR updates shared build/test toolchain versions by editing individual package manifests, but the same tools are now expressed with different range styles and one package-specific pin. These differences do not appear to encode package-specific intent, so they make future upgrades and lockfile reviews harder than necessary.

Example
A future dependency bump now has to answer whether ^8, ^8.1.4, ^6, ^6.0.3, and one exact Vitest pin are intentional package-level policies or just incidental update drift. That is avoidable metadata complexity for one shared toolchain.

Suggested direction
Use a single workspace-level version policy for Vite, @vitejs/plugin-react, Vitest, coverage, and Node types. A pnpm catalog would make the dependency update read as one coherent toolchain upgrade instead of several near-duplicate local edits.

For Agents
Inspect pnpm-workspace.yaml and the changed package.json files. Preserve the resolved tool versions, but move shared dev-tool versions into a pnpm catalog or otherwise normalize the same specifier across packages. Prove the lockfile remains equivalent after reinstall.

Vite 8 upgrade is not verified for the production UI bundle

What's wrong
The changed dependency affects vite build, but the validated package build path only runs TypeScript for node-ui. That leaves the shipped UI bundle path untested for this major Vite/plugin-react upgrade, so CI can go green while the production dashboard build is broken.

Example
A regression in Vite 8 production bundling could still pass pnpm run build:packages because @origintrail-official/dkg-node-ui only type-checks there. A direct check like pnpm --filter @origintrail-official/dkg-node-ui run build:ui is the behavior that would fail if the upgraded Vite/plugin-react stack cannot emit the shipped UI bundle.

Suggested direction
Add a CI/build validation step that executes the node-ui production Vite build, or document evidence from an equivalent existing job if one is intended to cover it.

For Agents
Look at packages/node-ui/package.json, root build scripts, and CI. Preserve the existing package build behavior, but add validation for the Vite production UI bundle after this dependency upgrade, either by running pnpm --filter @origintrail-official/dkg-node-ui run build:ui in CI for this lane or by making an existing validated build target include it intentionally.

"vitest": "^4.0.18"
},
"publishConfig": {
Expand Down
2,151 changes: 1,064 additions & 1,087 deletions pnpm-lock.yaml
View file
Open in desktop

Large diffs are not rendered by default.

Loading