Update tooling and dependencies

[morisil]

Summary

• Gradle wrapper 9.6.1 → 9.7.1
• Kotlin 2.4.10 → 2.4.20
• ASM 9.9.1 → 9.10.1
• JReleaser plugin 1.25.0 → 1.26.0
• binary-compatibility-validator 0.18.1 → 0.18.2
• xemantic-conventions plugin 0.7.0 → 0.7.1
• yarn.lock regenerated via kotlinUpgradeYarnLock for the new Kotlin JS tooling

Already at latest: xemantic-kotlin-test 1.17.5, Dokka 2.2.0, maven-publish 0.37.0, version-catalog-update 1.1.1.

Dependabot alerts

All 12 open alerts point at transitive npm packages of the Kotlin/JS test tooling in kotlin-js-store/yarn.lock.
The two webpack alerts are already fixed by the regenerated lock (webpack 5.108.1).
The rest are pinned via yarn resolution(...) entries in build.gradle.kts, applied to both the JS and the wasm yarn workspace:

package	was	pinned	pulled in by
fast-uri	3.1.5	3.1.6	ajv
js-yaml	4.3.1	4.3.2	mocha
serialize-javascript	6.0.2	7.0.5	mocha
diff	7.0.0	8.0.3	mocha
qs	6.15.3	6.16.0	body-parser

kotlin-js-store/wasm/yarn.lock was never committed before and is now tracked too.

rootPackageJson/wasmRootPackageJson do not track resolutions as task inputs, so they must be forced with --rerun after changing them — documented in CLAUDE.md and in a comment in the build script.

Verification

Full ./gradlew build passes locally, including all test targets (mocha-based JS and wasm tests included) and apiCheck.

🤖 Generated with Claude Code

[claude]

Review

This is a routine, mechanical dependency/tooling bump — reviewed the full diff across gradle/libs.versions.toml, the Gradle wrapper files, gradlew/gradlew.bat, and kotlin-js-store/yarn.lock.

Code quality / best practices

• All version bumps are patch/minor (Gradle 9.6.1→9.7.1, Kotlin 2.4.10→2.4.20, ASM, JReleaser, binary-compatibility-validator, xemantic-conventions). Scope is tight and matches the stated summary — no unrelated changes bundled in.
• gradlew/gradlew.bat comment-only diffs ("Gradle" → "gradlew") are expected artifacts of the standard wrapper regeneration and not something to hand-revert.
• yarn.lock was regenerated via kotlinUpgradeYarnLock rather than hand-edited, which is the correct way to keep it in sync with the new Kotlin/JS tooling.

Potential issues

• The yarn.lock diff pulls in some larger transitive jumps beyond the direct Kotlin bump, e.g. webpack-cli 6.0.1 → 7.2.1 (major) and ajv-formats 2.1.1 → 3.0.1 (major), plus pruning of now-unused packages (@types/eslint*, @webpack-cli/* sub-packages, terser-webpack-plugin, glob-to-regexp, etc.) in favor of minimizer-webpack-plugin. These are transitive build-tooling deps controlled by the Kotlin/JS Gradle plugin, not hand-picked, so they're low risk, but worth a mention since major-version transitive bumps occasionally change JS build behavior (e.g. webpack CLI flag/output changes) — worth a quick sanity check of the jsBrowserProductionWebpack/test output if this project has a non-trivial JS target, beyond the plain build you already ran.
• The Gradle wrapper .jar is a binary diff and can't be reviewed as text; it should be checked against the official checksum but I'd assume CI's build-gradle.yml shared workflow (which already runs on this PR) or a wrapper-validation step catches a mismatched/tampered wrapper. Worth confirming that validation is actually part of the shared workflow if it isn't already.

Security

• No security concerns in the reviewed diff — this is a version-catalog and lockfile update with no source/logic changes. Bumping ASM, JReleaser, BCV, and Kotlin to newer patch releases is generally a positive from a security-maintenance standpoint.

Test coverage

• No new tests needed — this PR touches only build tooling and dependency versions, no application code. The PR description states ./gradlew build passes locally including apiCheck, which is the right verification for this kind of change.

Overall: looks safe to merge. Only soft suggestion is the JS-tooling major-version transitive bumps noted above, if this template ships a non-trivial Kotlin/JS target worth a manual look.

[claude]

Review

Reviewed the diff (Gradle wrapper bump, Kotlin 2.4.20, ASM/JReleaser/BCV/conventions-plugin bumps, and the npm resolution(...) pins for Dependabot alerts).

Overall: looks good. Clean, well-scoped tooling update with clear rationale.

Code quality

• The npmResolutions map applied to both YarnRootExtension and WasmYarnRootExtension via plugins.withType<...> is a nice DRY way to keep the JS and wasm yarn workspaces in sync, and the comment documenting the required --rerun invocation (since these tasks don't track resolution(...) as a task input) is exactly the kind of non-obvious gotcha that belongs in a code comment — good call putting it in both build.gradle.kts and CLAUDE.md.
• CLAUDE.md additions follow the semantic-line-break convention and stay focused on non-obvious facts (task-input gotcha, Dependabot scan target), consistent with the file's own stated rules.

Correctness / verification

• I diffed gradlew/gradlew.bat against the actual upstream Gradle 9.7.1 wrapper scripts to make sure the "Gradle start up script" → "gradlew start up script" and "ksh Gradle" → "ksh gradlew" wording changes weren't an accidental find/replace corruption — confirmed they match upstream's own wrapper template for 9.7.1, so that's expected wrapper-regen noise, not a bug.
• kotlin-js-store/wasm/yarn.lock being newly tracked (previously generated but gitignored/untracked) is a good fix for build reproducibility — worth double-checking the wasm target isn't excluded somewhere in .gitignore that would silently stop future updates from being tracked (I didn't find such an exclusion, but worth a second look since it's easy to miss).

Security

• The whole point of this PR is resolving 12 Dependabot alerts via yarn resolution() pins (fast-uri, js-yaml, serialize-javascript, diff, qs) plus the webpack 5.108.1 bump — this is the right approach for transitive npm deps that can't be fixed by bumping the direct Kotlin/JS tooling dependency alone. No concerns here.
• One thing worth confirming (can't verify from the diff alone): were the new pinned versions (e.g. diff@8.0.3, serialize-javascript@7.0.5) checked for breaking API changes relative to the old majors (diff 7→8, serialize-javascular 6→7)? Since these are dev-only test tooling transitive deps (via mocha), a major bump is low risk, but worth a one-line confirmation in the PR description that apiCheck/mocha tests actually exercise those code paths (the PR body already says the full build including mocha-based tests passed, which covers this).

Test coverage

• No production code changed, so no new tests needed. The PR description's verification section (full ./gradlew build including JS/wasm mocha tests and apiCheck) is appropriate evidence for a pure tooling/dependency bump.

Minor / nice-to-have

• Consider whether the npmResolutions map and its Dependabot-pin comment could eventually be extracted if this pattern grows (e.g., if more than a handful of pins accumulate over time), but for 5 entries the current inline form is perfectly readable — no change needed now.

No blocking issues found.

[claude]

Review

This is a routine dependency-maintenance PR (Gradle wrapper, Kotlin, ASM, JReleaser, BCV, xemantic-conventions bumps + Dependabot npm pins). No production source changed. Overall it's clean and well-documented; a few notes below.

Code quality / build script

• build.gradle.kts: the npmResolutions map + plugins.withType<YarnPlugin>/WasmYarnPlugin blocks are a reasonable, minimal way to force transitive npm pins for both the JS and Wasm yarn workspaces without duplicating the resolution list. Good use of a single source of truth for the pinned versions.
• The comment above npmResolutions documenting the exact --rerun invocation is a nice touch — it's the kind of non-obvious, easy-to-forget command that's worth having inline as well as in CLAUDE.md.
• gradlew/gradlew.bat comment changes ("Gradle" → "gradlew") come from the upstream Gradle 9.7.1 wrapper script generator, not from this PR's own edits — worth a quick sanity check that this wasn't a local hand-edit, but it looks like stock wrapper output.

Potential issues

• diff is force-resolved from ^7.0.0 (required by mocha) to 8.0.3 — a major version jump, not just a patch/minor pin. Since resolution() overrides semver entirely, mocha will load an API surface it didn't declare compatibility with. The PR says the full build (including mocha-based JS/wasm tests) passes locally, which is reassuring, but a major-version force-resolution is inherently riskier than the other patch-level pins here (fast-uri, js-yaml, qs, serialize-javascript) — might be worth a one-line callout in the PR description/CLAUDE.md distinguishing "safe patch pins" from "this one changed mocha's diff-rendering dependency by a major version," in case a future upgrade of mocha silently reintroduces the vulnerable range and the override starts masking a real incompatibility instead of just a version number.
• Similarly qs is pinned to 6.16.0 while the range requested by body-parser is ~6.15.1 (patch-only) — same override pattern, lower risk since qs 6.16.0 is a minor bump, but flagging alongside the diff one since both step outside the range the dependent package actually asked for.

Security

• The stated purpose (pinning patched transitive npm deps flagged by Dependabot) is exactly the right fix for this class of alert, better than waiting on upstream mocha/ajv/body-parser releases.
• Newly tracked kotlin-js-store/wasm/yarn.lock closes a real gap — untracked lock files are themselves a supply-chain risk (non-reproducible installs), so good catch bringing it under version control.

Test coverage

• No source/tests changed; verification relies on the full ./gradlew build + apiCheck run described in the PR body. That's appropriate for a dependency-bump PR — nothing further needed here.

Nothing blocking. The major-version diff override is the one thing I'd double check consciously (e.g. skim mocha's changelog for diff 8.x usage) rather than relying solely on the current test run, since a passing suite doesn't guarantee every code path through mocha's diff rendering was exercised.

[claude]

Review

Solid, well-documented dependency/tooling bump. The npmResolutions pattern for pinning transitive npm packages flagged by Dependabot is a nice reusable fix (applied identically to both YarnRootExtension and WasmYarnRootExtension via plugins.withType<>), and the CLAUDE.md additions are genuinely non-obvious gotchas worth keeping — they follow the file's own "don't document what's discoverable from source" rule well.

A few things worth double-checking before merge:

1. Configuration cache re-enabled (gradle.properties) — the removed comment said "caching seems incompatible with jreleaser," and both workflow files drop --no-configuration-cache. The new CLAUDE.md entry explains this as a harmless one-time cache invalidation per daemon lifecycle (JReleaser bumping a marker file), but that's a meaningfully different claim than "incompatible." Since CI spins up a fresh daemon per run, this "harmless once per daemon" invalidation effectively means CI gets zero benefit from configuration caching (it always misses on the first/only build), while adding re-work risk if the assumption is ever wrong for jreleaserAnnounce specifically. Worth confirming this was actually validated with publishToMavenCentral/jreleaserAnnounce in CI, not just a local ./gradlew build, since the release workflow is the highest-blast-radius path in this repo (Maven Central + GitHub release announce) and configuration-cache correctness bugs with third-party plugins tend to surface only when there's a stale cache from a previous invocation, which a single local run won't reproduce.

2. gradlew/gradlew.bat comment changes — the boilerplate header comments changed from "Gradle start up script..." / "Execute Gradle" to "gradlew start up script..." / "Execute gradlew" (lines 23, 32 in gradlew; similar in gradlew.bat). This is cosmetic and harmless, but it's an unusual diff to come out of a routine wrapper version bump (normally only the version/checksum lines change) — worth a quick sanity check that this came from the real gradle wrapper task output for 9.7.1 and not a hand-edit or a different generation path, just so the wrapper script stays byte-for-byte reproducible from upstream.

3. No test coverage added, which is appropriate for a pure dependency/tooling PR — the described verification (./gradlew build including JS/wasm mocha tests and apiCheck) is the right kind of check for this change. Just flagging that the configuration-cache change in particular isn't something apiCheck/unit tests would catch — it's really only exercised by the actual CI publish path.

No security concerns — the yarn resolution() pins move transitive versions forward to patched releases, and the new kotlin-js-store/wasm/yarn.lock is properly autogenerated (has the standard "DO NOT EDIT" header, matches the yarn lockfile format).

Nice attention to documenting the "why" in CLAUDE.md rather than just making the change silently.

[claude]

Review

Overall this is a clean, mechanical dependency/tooling bump with a reasonable verification story (full ./gradlew build including JS/wasm tests and apiCheck). One thing stands out that's worth fixing before merge.

Stale/broken CLAUDE.md entry

The new "Known gotchas" entry says:

The rootPackageJson and wasmRootPackageJson tasks do not track yarn resolution(...) entries as inputs, so after changing them the lock files stay stale unless these tasks are forced with --rerun (see the comment above npmResolutions in build.gradle.kts for the full command).

This describes the yarn-resolution approach added in "Pin patched npm packages flagged by Dependabot via yarn resolutions", but that approach was reverted two commits later in "Drop yarn resolutions for Dependabot alerts on test tooling". Checking the final diff (gh pr diff 48 --name-only) confirms build.gradle.kts is not touched by this PR at all, and there is no npmResolutions symbol anywhere in the repository (grep -rn "npmResolutions" . on main returns nothing). So this entry points future readers (human or AI) at a comment and a build-script mechanism that don't exist, which is exactly the kind of dangling context CLAUDE.md's own rules warn against. It should be removed or reworded — the very next entry ("Dependabot alerts on kotlin-js-store/yarn.lock … dismiss them on GitHub instead of forcing versions via yarn resolutions") already documents the approach that was actually kept, and directly contradicts this stale one.

PR description no longer matches the final diff

Related to the above: the description's "Dependabot alerts" section and the resolutions table describe the yarn-resolutions approach, and says kotlin-js-store/wasm/yarn.lock "was never committed before and is now tracked too." Neither is true of the final state — build.gradle.kts and kotlin-js-store/wasm/yarn.lock don't appear in the diff at all (gh pr diff 48 --name-only). Worth updating the description so reviewers aren't evaluating against a plan that was superseded by the last commit.

Everything else looks fine

• Version bumps in gradle/libs.versions.toml and the wrapper are straightforward and internally consistent.
• Enabling org.gradle.configuration-cache in gradle.properties together with dropping --no-configuration-cache from both CI workflows is consistent — no leftover flag mismatches.
• The new CLAUDE.md gotchas about the JReleaser marker-file cache invalidation and the kotlin-web-helpers warning are the kind of non-obvious, non-derivable info this file is meant to hold — good additions.
• gradlew/gradlew.bat comment-only wording changes ("Gradle" → "gradlew") look like upstream template churn from the wrapper version bump, not an intentional edit — harmless either way.
• No test coverage concerns beyond what's already exercised by the full build; this is a tooling/dependency-only change so that's appropriate.

🤖 Generated with Claude Code