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: Centralize the toolchain versions instead of scattering near-duplicate ranges
What's wrong
This PR is primarily a toolchain upgrade, but it encodes the upgrade as one-off edits across package manifests with inconsistent ranges. In a 45-package workspace, that makes the version policy harder to audit and makes the next upgrade more manual than it needs to be. The cleaner move is to delete the repeated version choices from individual packages and let one canonical workspace declaration own them.
Example
A future toolchain bump now requires hunting through several manifests and deciding whether ^8, ^8.1.3, ^6, ^6.0.3, exact 4.1.9, and ^4.0.18 are intentional differences or accidental drift. The lockfile currently hides that drift by resolving shared versions, but the manifests do not communicate a single policy.
Suggested direction
Use a workspace catalog or another repo-level dependency policy for shared dev tooling, then express Vite, @vitejs/plugin-react, Vitest, coverage, and Node types through that policy. If a package truly needs a different range or exact pin, make that exception explicit and local.
For Agents
Look at pnpm-workspace.yaml and the package manifests that declare Vite, plugin-react, Vitest, coverage, and Node types. Preserve the same resolved versions, but introduce a single dependency source of truth such as pnpm catalogs or a workspace-level policy, then rewrite the touched manifests to reference it consistently. Verify with pnpm install --lockfile-only and a manifest diff showing only intentional version-policy changes.
Node UI Vite 8 upgrade is not verified against the production bundle
What's wrong
This diff upgrades the major Vite toolchain used to create the shipped dist-ui dashboard, but the existing automated checks do not appear to exercise that production build path. That leaves a real packaging/runtime risk: the dev server can still work while the static bundle shipped with the node package is broken.
Example
A regression where pnpm --filter @origintrail-official/dkg-node-ui run build:ui fails, or emits no usable dist-ui/index.html, would not be caught by the current node-ui unit tests or Playwright dev-server e2e lane.
Suggested direction
Add CI or documented PR validation that runs the Node UI production bundle build after the Vite/plugin upgrade, preferably a targeted build:ui smoke rather than relying only on dev-server e2e.
Confidence note
The repository CI comments state that the shared PR build skips the Node UI dist-ui bundle, and the Playwright lane starts pnpm dev:ui, so I do not see an existing PR check that proves the production Vite bundle still builds after this major upgrade.
For Agents
Check packages/node-ui/package.json, scripts/build.mjs, and .github/workflows/ci.yml. Preserve the existing fast CI split if needed, but add a targeted validation step for pnpm --filter @origintrail-official/dkg-node-ui run build:ui and assert packages/node-ui/dist-ui/index.html exists after the Vite 8 build.
There was a problem hiding this comment.
🟡 Issue: Vite 8 production UI build is not verified by the PR test lanes
What's wrong
The dependency major bump changes the tool used to produce the shipped Node UI static bundle, but the existing PR CI path intentionally skips that bundle build. That leaves the riskiest changed behavior unverified: whether the published UI still builds under Vite 8.
Example
A regression in Vite 8 production bundling, asset emission, or plugin-react production transform could pass pnpm run build:packages, node-ui vitest, and Playwright dev-server e2e, then fail only when pnpm --filter @origintrail-official/dkg-node-ui build:ui runs for a release or publish artifact.
Suggested direction
Add or report validation that runs the production Vite build path affected by this major upgrade, not only package builds, unit tests, or dev-server e2e.
Confidence note
I could verify the repository CI config in the worktree, but not any external PR-run artifacts. If the PR description links a successful manual build:ui run, this may already be covered as validation evidence outside the diff.
For Agents
Check packages/node-ui/package.json scripts and .github/workflows/ci.yml. Add PR validation for the changed Vite production path, for example pnpm --filter @origintrail-official/dkg-node-ui build:ui; if keeping the graph-viz Vite bump, also consider pnpm --filter @origintrail-official/dkg-graph-viz demo:build or document manual evidence.
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.
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.
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.
dependabot
Bot
force-pushed
the
dependabot/npm_and_yarn/dev-tooling-92f2eb09f8
branch
2 times, most recently
from
3f323fa to
af57bdd
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.0` | | [@vitest/coverage-v8](https://github.com/vitest-dev/vitest/tree/HEAD/packages/coverage-v8) | `4.0.18` | `4.1.9` | | [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.9` | | [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) | `6.4.2` | `8.1.3` | | [@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.0 - [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.9 - [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.9/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.9 - [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.9/packages/vitest) Updates `vite` from 6.4.2 to 8.1.3 - [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.3/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
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.
1 participant
Bumps the dev-tooling group with 7 updates in the / directory:
22.19.1126.1.04.0.184.1.94.21.04.23.04.0.184.1.96.4.28.1.34.7.06.0.31.59.11.61.1Updates
@types/nodefrom 22.19.11 to 26.1.0Commits
Updates
@vitest/coverage-v8from 4.0.18 to 4.1.9Release notes
Sourced from @vitest/coverage-v8's releases.
... (truncated)
Commits
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.21f2d318chore: release v4.1.1Updates
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.9Release notes
Sourced from vitest's releases.
... (truncated)
Commits
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.618af98cfix(browser): simplify orchestrator otel carrier (#10285)3188260feat(browser): provide project reference inToMatchScreenshotResolvePath(#...Updates
vitefrom 6.4.2 to 8.1.3Release notes
Sourced from vite's releases.
... (truncated)
Changelog
Sourced from vite's changelog.
... (truncated)
Commits
578ffb8release: v8.1.37103c3afix(deps): bumpes-module-lexerto 2.3.0 (#22838)1534d36fix(css): inject inlined CSS after the shebang line (#22717)c4acd69fix(ssr): correct stacktrace column position for first line (#22828)2c53054fix: preload css for nested dynamic imports (#22759)ba31193release: v8.1.20d3bd7cfix(deps): revert es-module-lexer to 2.1.0 (#22827)efb98ccfix: restore, "fix: resolve pnpm .modules.yaml from workspace root instead of...cf97711fix: revert, "fix: resolve pnpm .modules.yaml from workspace root instead of ...cccef55fix: revert, "fix: escape ids with multiple null bytes (#22687)"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...