Skip to content

chore: update dependencies 2026-09-08 - #113

Open
claude[bot] wants to merge 1 commit into
mainfrom
agent/update-deps-20260908-140444
Open

chore: update dependencies 2026-09-08#113
claude[bot] wants to merge 1 commit into
mainfrom
agent/update-deps-20260908-140444

Conversation

@claude

@claude claude Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

Summary

  • @changesets/changelog-github: 1.0.01.0.1 (devDependencies)
  • @changesets/cli: 3.0.13.0.2 (devDependencies)
  • @rsbuild/core: 2.2.12.2.3 (devDependencies)
  • @rslib/core: 0.23.21.0.0 (devDependencies)
  • @rspack/core: 2.2.12.2.2 (devDependencies)
  • @types/node: 26.4.026.4.1 (devDependencies)
  • @types/react-dom: 19.2.519.2.7 (devDependencies)
  • @typescript-eslint/parser: 8.68.08.69.0 (devDependencies)
  • agent-browser: 0.35.20.36.0 (devDependencies)
  • browserslist: 4.28.84.28.9 (devDependencies)
  • typescript-eslint: 8.68.08.69.0 (devDependencies)
  • vitest: 4.1.115.0.0 (devDependencies)

All changes are devDependency-only, so no changeset was created.

Validation checklist

  • Step 2a: Linting
  • Step 2b: Tests
  • Step 2c: Web sample app

@pkg-pr-new

pkg-pr-new Bot commented Sep 8, 2026

Copy link
Copy Markdown

Open in StackBlitz

pnpm add https://pkg.pr.new/@workleap/logging@113

commit: 41e0a0b

"@rslib/core": "0.23.2",
"@typescript-eslint/parser": "8.68.0",
"@rsbuild/core": "2.2.3",
"@rslib/core": "1.0.0",

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Medium — unsupported peer combination (workleap-web-configs skill)

@rslib/core is bumped across a major (0.23.21.0.0), but @workleap/rslib-configs@1.2.1 — kept at the same version in this PR — declares:

'@workleap/rslib-configs@1.2.1':
  peerDependencies:
    '@rslib/core': ^0.23.2

1.0.0 does not satisfy ^0.23.2, so the installed tree no longer matches the config package's declared support range (pnpm install without --frozen-lockfile reports it as an unmet peer; CI only passes because strict-peer-dependencies is not enabled and defineBuildConfig happens to still produce a valid config for rslib 1.x).

Note also that the validation checklist in the PR body (2a lint, 2b tests, 2c web sample app) never runs pnpm build-pkg, which is the only step that exercises rslib build — the riskiest part of this bump was not covered by the agent's own validation.

Fix: keep @rslib/core pinned to 0.23.2 until a @workleap/rslib-configs release peering on @rslib/core: ^1.0.0 is available, then bump both together in the same PR:

Suggested change
"@rslib/core": "1.0.0",
"@rslib/core": "0.23.2",

Comment thread pnpm-lock.yaml
'@workleap/eslint-configs':
specifier: 2.0.5
version: 2.0.5(@eslint/js@9.39.2)(@typescript-eslint/eslint-plugin@8.68.0(@typescript-eslint/parser@8.68.0(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript@6.0.3))(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript@6.0.3))(@typescript-eslint/parser@8.68.0(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript@6.0.3))(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript-eslint@8.68.0(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript@6.0.3))(typescript@6.0.3)(vitest@4.1.11(@types/node@26.4.0)(vite@8.2.2(@types/node@26.4.0)(jiti@2.7.0)(yaml@2.9.0)))
version: 2.0.5(@eslint/js@9.39.2)(@typescript-eslint/eslint-plugin@8.68.0(@typescript-eslint/parser@8.69.0(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript@6.0.3))(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript@6.0.3))(@typescript-eslint/parser@8.69.0(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript@6.0.3))(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript-eslint@8.69.0(eslint@9.39.2(jiti@2.7.0)(supports-color@7.2.0))(supports-color@7.2.0)(typescript@6.0.3))(typescript@6.0.3)(vitest@4.1.11(@types/node@26.4.1)(vite@8.2.2(@types/node@26.4.1)(jiti@2.7.0)(yaml@2.9.0)))

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Low — stale peer resolution leaves two vitest majors in the lockfile (pnpm skill)

Before this PR the lockfile contained exactly one vitest (4.1.11). After it, both are present:

3148:  vitest@4.1.11:
3189:  vitest@5.0.0:
6452:  vitest@4.1.11(@types/node@26.4.1)(vite@8.2.2(...)):   # optional: true
6480:  vitest@5.0.0(@types/node@26.4.1)(vite@8.2.2(...)):

pnpm update -r --latest only re-resolved the declared specifier in packages/logging, so @workleap/eslint-configs@2.0.5 is still resolved with (vitest@4.1.11...) for the root importer (this line) and for samples/web (line 244), while packages/logging resolves it with vitest@5.0.0. Consequences: the whole vitest@4.1.11 + @vitest/*@4.1.11 tree is still installed as an optional dep of @vitest/eslint-plugin, and root/samples/web lint against vitest 4 semantics while the package's tests run on vitest 5.

Fix: re-resolve the lockfile so all three importers share vitest@5.0.0pnpm dedupe (or delete pnpm-lock.yaml entries for the stale resolution and run pnpm install --no-frozen-lockfile) — and commit the updated lockfile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants