chore: update dependencies 2026-08-25

[claude]

Summary

• react: 19.2.7 → 19.2.8 (dependencies)
• react-dom: 19.2.7 → 19.2.8 (dependencies)
• @changesets/changelog-github: 0.7.0 → 1.0.0 (devDependencies)
• @changesets/cli: 2.31.0 → 3.0.1 (devDependencies)
• @rsbuild/core: 2.1.5 → 2.1.13 (devDependencies)
• @rspack/core: 2.1.3 → 2.1.10 (devDependencies)
• @types/node: 26.1.1 → 26.2.0 (devDependencies)
• @types/react: 19.2.17 → 19.2.18 (devDependencies)
• @types/react-dom: 19.2.3 → 19.2.5 (devDependencies)
• @typescript-eslint/parser: 8.63.0 → 8.67.0 (devDependencies)
• agent-browser: 0.31.1 → 0.34.0 (devDependencies)
• browserslist: 4.28.5 → 4.28.8 (devDependencies)
• pkg-pr-new: 0.0.75 → 0.0.88 (devDependencies)
• prettier: 3.9.4 → 3.9.6 (devDependencies)
• syncpack: 15.3.2 → 15.3.3 (devDependencies)
• turbo: 2.10.4 → 2.10.11 (devDependencies)
• typescript-eslint: 8.63.0 → 8.67.0 (devDependencies)
• vitest: 4.1.10 → 4.1.11 (devDependencies)

No peerDependencies changed, so no range narrowing affects consumers.

Reverted update

typescript was left at 6.0.3 instead of being bumped to 7.0.2. typescript-eslint@8.67.0 throws an unconditional error on any TypeScript major >= 7, which prevents ESLint from loading eslint.config.ts at all. There is no clean migration available until typescript-eslint ships TypeScript 7 support, so the bump was reverted and tracked in #107.

No changeset

Every change to @workleap/logging is devDependency-only — the package declares no dependencies or peerDependencies — so no changeset was created.

Validation checklist

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

[pkg-pr-new]

Open in StackBlitz

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

commit: 81fde99

[claude]

Medium — pnpm skill (dependency resolution / deduplication)

Pinning typescript-eslint and @typescript-eslint/parser to 8.67.0 leaves the pins one patch behind what the transitive graph resolves to, and this PR newly introduces a duplicate @typescript-eslint/* tree in pnpm-lock.yaml.

@vitest/eslint-plugin@1.6.27 (pulled in transitively by @workleap/eslint-configs) has a floating ^8 range on @typescript-eslint/utils, which resolved to 8.68.0:

# pnpm-lock.yaml
'@vitest/eslint-plugin@1.6.27(...)':
  dependencies:
    '@typescript-eslint/scope-manager': 8.68.0
    '@typescript-eslint/utils': 8.68.0(eslint@9.39.2(jiti@2.7.0))(typescript@6.0.3)

Seven packages are now installed twice — project-service, scope-manager, tsconfig-utils, types, typescript-estree, utils, visitor-keys — each at both 8.67.0 and 8.68.0. On main there is exactly one copy of each (8.63.0), so this is introduced by this change.

The consequence is that pnpm lint loads two independent typescript-estree instances, so the type-aware rules from @vitest/eslint-plugin build their own TypeScript program separate from the one @typescript-eslint/parser created — duplicated type-checking work and memory on every lint run, plus a real risk of divergent behaviour between plugins that are supposed to share parser services. It also contradicts the repo's own .syncpackrc.js rule "Packages should have a single version across the repository."

There is no compatibility reason to hold at 8.67.0: 8.68.0 declares the identical peer range typescript: '>=4.8.4 <6.1.0', which typescript@6.0.3 satisfies, so it is unaffected by the TypeScript 7 revert described in the PR body.

Fix: bump the pins to 8.68.0 in all three manifests — root package.json (@typescript-eslint/parser, typescript-eslint), packages/logging/package.json (same two), and samples/web/package.json (same two) — then re-run pnpm install --no-frozen-lockfile so the tree dedupes to a single version.

Suggested change

	"typescript-eslint": "8.67.0"
	"typescript-eslint": "8.68.0"

If holding at 8.67.0 is deliberate, dedupe downward instead by adding an override in pnpm-workspace.yaml:

overrides:
  "@typescript-eslint/utils": 8.67.0
  "@typescript-eslint/scope-manager": 8.67.0

[claude]

Low — release-tooling configuration

This is a two-major jump in the config layer that .changeset/config.json is validated against. @changesets/cli@3.0.1 bundles @changesets/config@4.0.0:

# pnpm-lock.yaml
'@changesets/cli@3.0.1':
  dependencies:
    '@changesets/config': 4.0.0

but .changeset/config.json:2 still declares the schema for @changesets/config@2.3.0:

"$schema": "https://unpkg.com/@changesets/config@2.3.0/schema.json",

The config file was consistent before this bump and is now stale by two majors, so editor/CI JSON validation of .changeset/config.json is checking against a schema that no longer describes the installed tool.

Fix: update .changeset/config.json:2 to "$schema": "https://unpkg.com/@changesets/config@4.0.0/schema.json".

Worth calling out while you're there: .changeset/config.json also carries ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.onlyUpdatePeerDependentsWhenOutOfRange, an option whose name explicitly disclaims stability across patches. The validation checklist in this PR covers linting, tests, and the web sample app — none of which exercise changeset. Since the release pipeline (.github/workflows/changeset.yml → pnpm publish-pkg) is the only consumer of these two packages, a config-validation regression from the v2→v3 jump would first surface on merge to main. A pnpm changeset status --verbose run before merging would close that gap.