Skip to content

Validate Scala 3.9.0 LTS + Scala.js 1.22.0 on Mill 1.1.8; cut 0.3.1 (TJC-2274) - #29

Merged
arcaputo3 merged 2 commits into
mainfrom
tjc-2274-scala-3-9-validation
Sep 4, 2026
Merged

arcaputo3 merged 2 commits into
mainfrom
tjc-2274-scala-3-9-validation

Conversation

@arcaputo3

@arcaputo3 arcaputo3 commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Summary

Prerequisite for TJC-2273 (fast-mcp-scala → Scala 3.9.0 LTS). Scala 3.9.0 emits Scala.js 1.22 IR, which the linker bundled by Mill 1.1.x's ScalaJSConfigModule (IR ≤ 1.20) rejects; 0.3.0's explicit-scalaJSVersion path is the supported route, and until now the suite only proved it against Scala 3.8.2 on Mill 1.1.5.

  • Scala 3.9.0 LTS in every Scala.js integration fixture, example-scalajs, examples, and the README snippets (Scala.js stays 1.22.0). No plugin code change was needed — the suite passes as-is.
  • Mill 1.1.8 for the plugin build (.mill-version, launcher defaults, fixture/example headers) and, the part that actually decides which Mill the fixtures run in-process, a separate millTestkitVersion = "1.1.8". The compile target stays at millVersion = "1.1.5", so the supported floor is unchanged and the jar under test is the real consumer shape (0 "Mill version … is different than configured" warnings, previously 49).
  • The plugin's own scalaVersion stays at 3.8.2 on purpose and build.mill now says why: Mill 1.1.5 and 1.1.8 both compile build files with Scala 3.8.2, and a plugin built with newer Scala emits TASTy consumers' Mill cannot read.
  • Managed Bun 1.4.0 → 1.4.1 (released 2026-09-04) with checksums for all twelve release assets, verified against the release's SHASUMS256.txt; 1.4.1 writes lockfileVersion 2 so committed locks stay valid, and 1.4.0 stays in the table for explicit pins. @types/bun has not reached 1.4.1 on npm yet, so the shipped default pairs with a new DefaultBunTypesVersion = "1.4.0" instead of tracking Bun blindly (which would 404 every TypeScript frozen install on release day); modules that override bunVersion keep lockstep.
  • Version sweep 0.3.0 → 0.3.1 (README, example builds) and a 0.3.1 CHANGELOG entry.

Verification (local, macOS arm64, Mill 1.1.8, managed Bun 1.4.1)

  • millbun.compile, millbun.test: green
  • millbun.integration (full suite, in-process Mill 1.1.8 via mill-testkit 1.1.8): green, 0 version-mismatch warnings
  • example-scalajs (app.run, app.test.testForked), example-typescript (same), examples __.compile, scalafmt check: see CI
  • Consumer check: fast-mcp-scala on Scala 3.9.0 + this plugin at 0.3.1 (publishLocal) compiles JVM/JS/Native and its Bun conformance suite passes 42/42 (TJC-2273 PR)

Linear: TJC-2274

🤖 Generated with Claude Code

arcaputo3 and others added 2 commits September 4, 2026 11:13
…0.3.1 (TJC-2274)

Scala 3.9.0 emits Scala.js 1.22 IR, which the linker bundled by Mill 1.1.x's
ScalaJSConfigModule (IR <= 1.20) rejects. 0.3.0's explicit-scalaJSVersion path
is the supported route, but the suite only proved it against Scala 3.8.2 on
Mill 1.1.5. Now:

- Every Scala.js fixture, example-scalajs, examples, and the README snippets
  build with Scala 3.9.0 LTS on Scala.js 1.22.0. No plugin code change needed.
- Mill 1.1.8 for the plugin build (.mill-version, launcher defaults, fixture
  and example headers) plus a separate millTestkitVersion = "1.1.8": the
  fixtures run Mill in-process via mill-testkit, so that pin is what decides
  which Mill they exercise (0 version-mismatch warnings, previously 49). The
  compile target stays at millVersion = "1.1.5"; the floor is unchanged.
- The plugin's own scalaVersion stays 3.8.2 on purpose (documented): Mill
  1.1.5 and 1.1.8 both compile build files with Scala 3.8.2, and a plugin
  built with newer Scala emits TASTy consumers' Mill cannot read.
- Version sweep 0.3.0 -> 0.3.1 and a 0.3.1 CHANGELOG entry.

Verified locally: millbun.compile/test, full millbun.integration (in-process
Mill 1.1.8), example-scalajs + example-typescript run/test, examples compile,
scalafmt check. Consumer check: fast-mcp-scala on Scala 3.9.0 with this
plugin at 0.3.1 (publishLocal) compiles JVM/JS/Native and passes its Bun
conformance suite.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…n version (TJC-2274)

Bun 1.4.1 shipped 2026-09-04. The managed default moves to it with checksums
for all twelve release assets taken from the release's SHASUMS256.txt (the
darwin-aarch64 archive was downloaded and re-hashed to confirm the table
matches). 1.4.1 writes lockfileVersion 2, so committed locks stay valid;
1.4.0 stays in the table for explicit bunVersion pins. CI's system-Bun jobs
follow, since the version check requires PATH Bun == bunVersion.

@types/bun has not reached 1.4.1 on npm, so the shipped default now pairs
with DefaultBunTypesVersion = "1.4.0" instead of tracking Bun blindly, which
would have 404'd every TypeScript frozen install on release day. Modules that
override bunVersion keep the lockstep behaviour. The "ambient types are
pinned" integration test asserts the new pairing.

Verified locally: millbun.test, full millbun.integration on managed 1.4.1,
example-scalajs + example-typescript run/test, examples compile, scalafmt.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@arcaputo3
arcaputo3 merged commit f98965c into main Sep 4, 2026
7 checks passed
@arcaputo3
arcaputo3 deleted the tjc-2274-scala-3-9-validation branch September 4, 2026 16:02
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.

1 participant