chore(deps)(deps-dev): bump the dev-tooling group across 1 directory with 7 updates#1358
chore(deps)(deps-dev): bump the dev-tooling group across 1 directory with 7 updates#1358dependabot[bot] wants to merge 1 commit into
Conversation
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
dependabot
Bot
requested review from
Jurij89,
branarakic and
zsculac
as code owners
| vitest: | ||
| specifier: ^4.0.18 | ||
| version: 4.0.18(@types/node@22.19.11)(happy-dom@20.8.9(bufferutil@4.1.0)(utf-8-validate@5.0.10))(jiti@2.7.0)(tsx@4.21.0)(yaml@2.9.0) | ||
| version: 4.1.9(@types/node@26.0.1)(@vitest/coverage-v8@4.1.9)(happy-dom@20.8.9(bufferutil@4.1.0)(utf-8-validate@5.0.10))(vite@8.1.0(@types/node@26.0.1)(esbuild@0.27.3)(jiti@2.7.0)(tsx@4.22.4)(yaml@2.9.0)) |
There was a problem hiding this comment.
🟡 Issue: Make the toolchain version policy explicit instead of lockfile-driven
What's wrong
This PR is a toolchain upgrade, but the structure leaves version ownership scattered. The manifests do not clearly say whether the workspace standard is Vitest 4.1.9, Vite 8.1.0, or simply whatever the current lockfile selected. That makes future maintenance harder because reviewers have to reverse-engineer policy from pnpm-lock.yaml rather than from a clear package-management boundary.
Example
A future dependency refresh can keep package manifests looking unchanged while moving the actual test/build stack again, because the intended versions live partly in one exact devnet pin and partly in lockfile resolution side effects.
Suggested direction
Centralize these build/test tool versions or update all relevant workspace manifests consistently. Avoid having one package exact-pin Vitest while the rest rely on old ranges that happen to resolve to the new version in this lockfile.
For Agents
Look at package.json, pnpm-workspace.yaml, and the workspace package manifests. Preserve the resolved Vite/Vitest versions, but move the version policy into a single explicit place, such as a pnpm catalog or consistent manifest spec updates, then regenerate pnpm-lock.yaml and verify pnpm install is stable.
| "three": "^0.184.0", | ||
| "typescript": "^5.7", | ||
| "vite": "^6", | ||
| "vite": "^8", |
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
33f382f to
c726e29
Compare
| "@types/react": "^19.0.0", | ||
| "@types/react-dom": "^19.0.0", | ||
| "@vitejs/plugin-react": "^4.4.0", | ||
| "@vitejs/plugin-react": "^6.0.3", |
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
c726e29 to
e6fb66c
Compare
| }, | ||
| "devDependencies": { | ||
| "vitest": "4.0.18" | ||
| "vitest": "4.1.9" |
There was a problem hiding this comment.
🟡 Issue: Don’t hide the workspace Vitest baseline in one devnet package
What's wrong
This adds a one-off exact version in a small devnet package while the same tool remains declared with broader, older ranges throughout the monorepo. That is dependency-policy drift: the lockfile carries a workspace-wide upgrade, but the manifest that explains why is local and easy to miss.
Example
A maintainer grepping package manifests would see most packages still on ^4.0.18, but a fresh lockfile update is constrained by devnet/edge-update-flow's exact 4.1.9 pin. That makes the intended Vitest baseline unclear.
Suggested direction
Make the Vitest upgrade explicit at the workspace level instead of using an exact pin in this one package. A pnpm catalog for shared toolchain versions would also solve the repeated Vite/Vitest/Node type version drift in this PR.
For Agents
Inspect all workspace package.json files that declare vitest and @vitest/coverage-v8. Preserve the intended Vitest 4.1.9 resolution, but express it through a single visible policy: either align the package specifiers or introduce a pnpm catalog/shared dependency policy and point packages at it. Verify pnpm install --lockfile-only does not churn unrelated entries afterward.
There was a problem hiding this comment.
🟡 Issue: Keep the devnet Vitest version policy consistent
What's wrong
This introduces a one-off dependency policy in a workspace where the surrounding devnet packages all use the same Vitest range. The lockfile already resolves the range to 4.1.9, so the exact pin adds maintenance state without simplifying anything.
Example
A future Vitest patch can be picked up by every other devnet through the shared ^4.0.18 policy, while edge-update-flow stays frozen until someone notices this one exception.
Suggested direction
Either keep this package on the same range policy as the rest of the devnet packages, or deliberately bump all Vitest manifest specifiers together. Avoid making one devnet carry an exact pin unless there is a documented package-specific reason.
For Agents
Review all vitest devDependency specifiers in root and devnet/*/package.json; preserve the resolved lockfile version if desired, but make the manifest policy consistent. A lockfile-only diff should prove the same Vitest version is installed after the change.
There was a problem hiding this comment.
🟡 Issue: Avoid making one devnet fixture a special-case Vitest pin
What's wrong
This introduces a single-package exception in a set of otherwise uniform devnet manifests. Dependency policy becomes harder to reason about because the lockfile upgrades the whole workspace, but only this fixture records the new exact version in its manifest.
Example
Running pnpm --filter @origintrail-official/dkg-devnet-edge-update-flow update vitest will behave differently from the neighboring devnet packages because this one is exact-pinned while the rest use the shared caret policy.
Suggested direction
Either align this package with the existing devnet caret range, or centralize/pin Vitest for the whole workspace. The current one-off exact pin reads like accidental dependency policy drift.
For Agents
Inspect all devnet package.json files and decide on one Vitest version policy. Preserve the resolved Vitest version if intended, but express it consistently, preferably via a shared workspace-level mechanism or by updating all devnet manifests the same way.
There was a problem hiding this comment.
🟡 Issue: Declare the Vitest upgrade policy instead of letting the lockfile carry it
What's wrong
This adds a new one-off exact Vitest pin while the rest of the workspace still advertises the older broad range. The lockfile then upgrades Vitest and coverage across many unrelated importers, so the repository’s actual test-toolchain version is implicit and harder to maintain. Future dependency refreshes will be noisy and reviewers will have to infer intent from lockfile churn rather than from a clear version policy.
Example
A maintainer looking at devnet/_bootstrap/package.json still sees vitest ^4.0.18, while pnpm-lock.yaml resolves that same specifier to 4.1.10. It is not clear whether 4.1.10 is a deliberate workspace-wide toolchain target or incidental resolver drift from this one exact pin.
Suggested direction
Pick one dependency-management shape: either centralize shared test-tool versions with a pnpm catalog/override and update all Vitest-related specs together, or keep this package-local pin from causing a repo-wide lockfile upgrade. Avoid mixing one exact pin, many loose 4.0-range manifests, and a lockfile-wide 4.1 resolution.
For Agents
Review all vitest/@vitest/coverage-v8 declarations across package.json files and pnpm-lock.yaml. Preserve the resolved behavior, but express the intended Vitest version policy in manifests or a pnpm catalog/central dependency policy. If only edge-update-flow needs 4.1.10, regenerate the lockfile without upgrading unrelated importers. Verify with pnpm install --frozen-lockfile and a representative test command.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
e6fb66c to
681c09a
Compare
| "devDependencies": { | ||
| "@origintrail-official/dkg": "workspace:*", | ||
| "@types/node": "^22", | ||
| "@types/node": "^26", |
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
3 times, most recently
from
af57bdd to
208b5bf
Compare
| "tsup": "^8.4.0", | ||
| "typescript": "^5.7.0", | ||
| "vite": "^6.4.2", | ||
| "vite": "^8.1.3", |
There was a problem hiding this comment.
🟡 Issue: Vite 8 raises the effective Node floor without updating the repo runtime contract
What's wrong
The changed dependency makes Vite-based workspaces require a newer Node patch level than the repository advertises. Because the repo still points users and CI at a broad Node 22, some supported-looking Node 22 installations can no longer reliably build the affected packages.
Example
A contributor or auto-update environment on Node 22.10 follows the repo’s 22 runtime hint, installs the new lockfile, then runs pnpm --filter @origintrail-official/dkg-graph-viz demo:build or pnpm run build:runtime; Vite 8 is outside its declared engine range and the UI/graph build is unsupported or can fail. Expected behavior is that the repo’s declared Node floor matches the upgraded tooling.
Suggested direction
Align the runtime contract with the new toolchain before merging: pin .nvmrc/docs/CI to a compatible minimum such as 22.12 or higher, or defer the Vite 8 upgrade until the project is ready to drop older Node 22.x environments.
Confidence note
CI that resolves .nvmrc value 22 to the latest 22.x may still pass; the break is for callers or update jobs running an older Node 22.x that the repo still appears to allow.
For Agents
Look at .nvmrc, root/package workflow Node setup, and the Vite consumers in packages/graph-viz, packages/network-sim, and packages/node-ui. Either keep Vite/plugin-react on versions compatible with the supported Node 22 range, or explicitly raise the repo Node contract to at least 22.12 and prove install plus UI/graph builds under that minimum.
There was a problem hiding this comment.
🟡 Issue: Vite 8 is resolved against a Vitest release that still declares Vite 7.3.2
What's wrong
The changed Vite 8 dependency causes packages that also run Vitest to resolve Vitest against a Vite version outside Vitest's own peer contract. That makes the test/build toolchain rely on an unsupported integration boundary, which can break CI or release workflows even when the lockfile installs.
Example
With this lockfile, pnpm --filter @origintrail-official/dkg-node-ui test runs Vitest 4.1.10 with Vite 8.1.3 even though Vitest's peer contract in the lockfile only accepts Vite 7.3.2. In strict peer installs this can fail dependency installation; otherwise Vitest may execute against unsupported Vite APIs. Expected behavior is that the resolved Vite version satisfies Vitest's declared peer range.
Suggested direction
Align the Vite and Vitest major versions instead of mixing Vite 8 with a Vitest lock entry that still declares Vite 7.3.2 as its supported peer.
Confidence note
The lockfile shows the peer contract mismatch directly; the exact runtime symptom should be verified by running the affected package test/build commands because pnpm may only warn for optional peer mismatches unless strict peer checking is enabled.
For Agents
Check the Vite/Vitest alignment in packages/graph-viz, packages/network-sim, packages/node-ui, and the root pnpm overrides. Either keep Vite on the supported 7.3.2 line for the current Vitest release, or move Vitest/coverage to a release whose peer contract explicitly accepts Vite 8. Prove the fix with pnpm install --frozen-lockfile and the affected test/build commands for those packages.
There was a problem hiding this comment.
🟡 Issue: Centralize the build/test toolchain instead of letting each manifest drift
What's wrong
This PR updates major build/test tooling through scattered manifest edits with different range precision and unresolved peer ownership. That makes the actual toolchain a lockfile side effect rather than a clear workspace contract, which is brittle for future upgrades and hard for maintainers to reason about.
Example
A future package install can keep the manifest text unchanged but reshuffle the peer slot for Vite depending on which nearby transitive dependency happens to provide esbuild; readers then have to inspect pnpm-lock.yaml to know which build toolchain a package is actually using.
Suggested direction
Introduce a single workspace-level version policy for the upgraded toolchain, then have the package manifests reference it consistently. If Vite 8 needs an esbuild peer in this repo, make that dependency explicit rather than letting pnpm satisfy it differently per importer.
For Agents
Look at all changed package manifests plus the root dependency policy. Preserve the intended upgrades, but move shared build/test tool versions (vite, @vitejs/plugin-react, vitest, @vitest/coverage-v8, @types/node, and any required peer such as esbuild) behind one workspace-level source of truth, such as pnpm catalogs or consistent root/package specs. Verify the lockfile resolves one intentional toolchain shape across graph-viz, network-sim, node-ui, and devnet tests.
There was a problem hiding this comment.
🟡 Issue: Vite 8 narrows the supported Node 22 range without updating the repo runtime pin
What's wrong
The dependency change makes Vite-based package scripts require a newer Node patch level than the repository currently advertises through .nvmrc. That can break builds/tests for users or runners that are correctly following the repo's Node 22 pin but are on Node 22.5-22.11.
Example
A developer or CI runner already on Node 22.11 can satisfy the repo's .nvmrc value of 22, but Vite-backed commands such as pnpm --filter @origintrail-official/dkg-node-ui run build:ui or graph-viz/network-sim Vite scripts are now outside Vite's supported engine range. Expected behavior is that the repo's pinned Node version remains sufficient for these package scripts.
Suggested direction
If Vite 8 is required, update the repo's Node contract to a concrete compatible version such as 22.12+ and keep CI/local docs aligned. Otherwise stay on a Vite version compatible with the currently advertised Node 22 range.
Confidence note
This depends on whether the project still intends to support all Node 22 patch releases. The repo pins .nvmrc to 22 and local comments reference Node 22.5-23.x, while the new Vite toolchain requires at least Node 22.12.
For Agents
Check the Node runtime contract in .nvmrc, CI setup-node usage, and Vite-backed packages (graph-viz, network-sim, node-ui). Either pin/declare Node 22.12+ or choose tool versions compatible with the intended Node 22 range. Prove the fix with an install plus at least one Vite build/test command under the documented Node version.
There was a problem hiding this comment.
🟡 Issue: Vite 8 raises the actual Node floor above the documented Node 22+ contract
What's wrong
This upgrade changes the effective development/build contract from “Node.js 22+” to “Node.js 22.12+ or 20.19+” for the Vite-backed workspaces, but the repo still tells users and automation that any Node 22 is acceptable. That creates an integration break for valid documented environments in the Node 22.0-22.11 range.
Example
A developer following the documented Node.js 22+ requirement with Node 22.10 or 22.11 can now hit engine rejection in stricter installs, or Vite/plugin runtime failures, when running workspace commands such as pnpm --filter @origintrail-official/dkg-node-ui build:ui or pnpm --filter @origintrail-official/dkg-network-sim build. Those Node versions satisfy the repo docs but not the new Vite 8 toolchain contract.
Suggested direction
Align the declared project Node requirement with the new toolchain, or choose dependency versions whose engine ranges still match the existing Node 22+ support promise.
Confidence note
The dependency engine requirement is explicit in the updated lockfile, but whether it hard-fails depends on the caller's package-manager engine settings and exact Node patch version.
For Agents
Look at the Vite 8 / @vitejs/plugin-react 6 upgrades in graph-viz, network-sim, and node-ui. Either preserve the documented Node 22+ compatibility by staying on a Vite/plugin line that supports all Node 22 patches, or update the repo/runtime contract to require Node >=22.12 and make .nvmrc/docs/CI explicit. Prove the fix by installing and running the affected Vite build commands on the lowest supported Node version.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
2 times, most recently
from
11a0bb9 to
b6efe8b
Compare
| "@types/react-dom": "^19", | ||
| "@types/three": "^0.183.1", | ||
| "@vitejs/plugin-react": "^4", | ||
| "@vitejs/plugin-react": "^6", |
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🟡 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.
There was a problem hiding this comment.
🔴 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.
There was a problem hiding this comment.
🟡 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.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
9 times, most recently
from
033dcd6 to
352c84a
Compare
…with 7 updates Bumps the dev-tooling group with 7 updates in the / directory: | Package | From | To | | --- | --- | --- | | [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) | `22.19.11` | `26.1.1` | | [@vitest/coverage-v8](https://github.com/vitest-dev/vitest/tree/HEAD/packages/coverage-v8) | `4.0.18` | `4.1.10` | | [tsx](https://github.com/privatenumber/tsx) | `4.21.0` | `4.23.0` | | [vitest](https://github.com/vitest-dev/vitest/tree/HEAD/packages/vitest) | `4.0.18` | `4.1.10` | | [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) | `6.4.2` | `8.1.4` | | [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/tree/HEAD/packages/plugin-react) | `4.7.0` | `6.0.3` | | [@playwright/test](https://github.com/microsoft/playwright) | `1.59.1` | `1.61.1` | Updates `@types/node` from 22.19.11 to 26.1.1 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node) Updates `@vitest/coverage-v8` from 4.0.18 to 4.1.10 - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v4.1.10/packages/coverage-v8) Updates `tsx` from 4.21.0 to 4.23.0 - [Release notes](https://github.com/privatenumber/tsx/releases) - [Changelog](https://github.com/privatenumber/tsx/blob/master/release.config.cjs) - [Commits](privatenumber/tsx@v4.21.0...v4.23.0) Updates `vitest` from 4.0.18 to 4.1.10 - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v4.1.10/packages/vitest) Updates `vite` from 6.4.2 to 8.1.4 - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v8.1.4/packages/vite) Updates `@vitejs/plugin-react` from 4.7.0 to 6.0.3 - [Release notes](https://github.com/vitejs/vite-plugin-react/releases) - [Changelog](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite-plugin-react/commits/plugin-react@6.0.3/packages/plugin-react) Updates `@playwright/test` from 1.59.1 to 1.61.1 - [Release notes](https://github.com/microsoft/playwright/releases) - [Commits](microsoft/playwright@v1.59.1...v1.61.1) --- updated-dependencies: - dependency-name: "@playwright/test" dependency-version: 1.61.1 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-tooling - dependency-name: "@types/node" dependency-version: 26.0.1 dependency-type: direct:development update-type: version-update:semver-major dependency-group: dev-tooling - dependency-name: "@vitejs/plugin-react" dependency-version: 6.0.3 dependency-type: direct:development update-type: version-update:semver-major dependency-group: dev-tooling - dependency-name: "@vitest/coverage-v8" dependency-version: 4.1.9 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-tooling - dependency-name: tsx dependency-version: 4.22.4 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-tooling - dependency-name: vite dependency-version: 8.1.0 dependency-type: direct:development update-type: version-update:semver-major dependency-group: dev-tooling - dependency-name: vitest dependency-version: 4.1.9 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-tooling ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
from
352c84a to
cb43569
Compare
1 participant
Bumps the dev-tooling group with 7 updates in the / directory:
22.19.1126.1.14.0.184.1.104.21.04.23.04.0.184.1.106.4.28.1.44.7.06.0.31.59.11.61.1Updates
@types/nodefrom 22.19.11 to 26.1.1Commits
Updates
@vitest/coverage-v8from 4.0.18 to 4.1.10Release notes
Sourced from @vitest/coverage-v8's releases.
... (truncated)
Commits
db616d2chore: release v4.1.10 (#10718)a7a61e7chore: release v4.1.9 (#10598)e61f2ddchore: release v4.1.8e4067b3fix(browser): disable clientcdpAPI whenallowWrite/allowExec: false[ba...a09d472chore: release v4.1.7a8fd24cchore: release v4.1.6e399846chore: release v4.1.5ac04bacchore: release v4.1.42dc0d62chore: release v4.1.3fc6f482chore: release v4.1.2Updates
tsxfrom 4.21.0 to 4.23.0Release notes
Sourced from tsx's releases.
... (truncated)
Commits
1dfad37docs: cite esbuild's extension-resolution model in node notes257bbbbfix: avoid redundant filesystem probes during module resolutionc178197feat: add multi-scenario startup benchmark suite51800acdocs: add Node internals knowledge base (notes/node)a305f36fix: isolate hook state per async module.register() registrationca501a9chore: upgrade skills-npm to v1.2.0596cd1ftest: cover __dirname, __filename, & require.cache in CJS TS file75d9bf0test: lock in lenient ESM for ambiguous and CJS-typed packages1472f3etest: cover ESM-syntax dependency with omitted "type" field1ce8463fix: resolve CommonJS directory requires inside dependencies (#803)Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for tsx since your current version.
Updates
vitestfrom 4.0.18 to 4.1.10Release notes
Sourced from vitest's releases.
... (truncated)
Commits
db616d2chore: release v4.1.10 (#10718)bae52b5fix(vm): fix external module resolve error with deps optimizer query for enco...a7a61e7chore: release v4.1.9 (#10598)934b0f5fix(pool): prevent test run hang on worker crash (#10543) [backport to v4] (#...7fb2965fix(browser): wait for orchestrator readiness before resolving browser sessio...a518019fix: fiximportOriginalwith optimizer and query import [backport to v4] (#...e61f2ddchore: release v4.1.8e4067b3fix(browser): disable clientcdpAPI whenallowWrite/allowExec: false[ba...a09d472chore: release v4.1.7a8fd24cchore: release v4.1.6Updates
vitefrom 6.4.2 to 8.1.4Release notes
Sourced from vite's releases.
... (truncated)
Changelog
Sourced from vite's changelog.
... (truncated)
Commits
a477454release: v8.1.4ab5dafafeat(legacy): prefer oxc as minifier (fix #21973) (#22468)173a1b6fix(ssr): align named export function call stacktrace column with Node (#22829)575c32cfix(build): add workaround for building on stackblitz (#22840)72a5e21fix(optimizer): avoid optimizer run for transform request before init (#22852)a9539d6chore(deps): update dependency postcss-modules to v9 (#22867)70435b2docs: fix incorrect@defaultforserver.cors(#22859)2c4a217build: remove the custom onLog function (#22878)c581b55build: replace deprecatedonwarnwithonLog(#22741)ea22fb3refactor: eliminate ineffectiveDynamicImport warn (#22876)Updates
@vitejs/plugin-reactfrom 4.7.0 to 6.0.3Release notes
Sourced from @vitejs/plugin-react's releases.
... (truncated)
Changelog
Sourced from @vitejs/plugin-react's changelog.
... (truncated)
Commits
640fd35release: plugin-react@6.0.3889efb0fix(deps): update all non-major dependencies (#1249)6c57dd4fix(plugin-react): use '/' base in bundledDev preamble to fix non-root base p...3cc33a7fix(deps): update react-related dependencies (#1245)c0f7c7fdocs: mention the Biome rule in the "Consistent components exports" section (...cd80f0ffix(deps): update all non-major dependencies (#1241)e38accafix(deps): update all non-major dependencies (#1227)9a9bb26perf(react): improve react compiler preset so that slightly more modules are ...6535b55release: plugin-react@6.0.2bf0e43bfeat(react): whitelist debugging-options (#1189)Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for
@vitejs/plugin-reactsince your current version.Updates
@playwright/testfrom 1.59.1 to 1.61.1Release notes
Sourced from @playwright/test's releases.
... (truncated)
Commits
39e3553cherry-pick(#41399): fix(test): load require-reached files as commonjs in syn...4328122chore: mark v1.61.1 (#41404)2c29a94fix(tracing): stop recording websocket frames outside of chunks (#41398)4324b19cherry-pick(#41367): fix(test): keep builtin expect matchers on base extend041e7e3cherry-pick(#41364): fix(har):WebSocketmessage timestamps should be in mi...b8a0fc3cherry-pick(#41309, #43149): Revert "fix(firefox): treat `navigationCommitted...b5a3175cherry-pick(#41319): fix(loader): support other node versionsd4724a9cherry-pick(#41290): feat(docker): add Ubuntu 26.04 (Resolute Raccoon) image1cc5a90cherry-pick(#41295): chore: PLAYWRIGHT_TRACING_NO_WEBSOCKET_FRAMES and PLAYWR...a6772bdcherry-pick(#41280): Revert "fix(trace-viewer): add keyboard navigation to `N...