Release v20.54.7

Summary

Bumps TypeScript to 7.0.2 (the new native/Go compiler, current latest on npm) across the repo. All four JS library packages (Arc, Arc.React, Arc.React.MVVM, Arc.Vite) build, type-check, lint, and pass their specs cleanly under TS7 - yarn install, yarn ci (clean → lint → build → test), and dotnet build -c Release (including TypeScript proxy generation in the TestApps) all pass with zero errors and zero warnings.

TypeScript version changes (old → new)

Package	File	Old	New
root workspace (@cratis/arc monorepo)	package.json (devDependencies)	6.0.3	7.0.2
TestApp AspNetCore	TestApps/AspNetCore/package.json	^6.0.3	^7.0.2
TestApp ArcCore	TestApps/ArcCore/package.json	^6.0.3	^7.0.2

Version-range prefixes were preserved (exact stays exact, ^ stays ^). No @types/* version entries were touched. There is no typescript peerDependency anywhere on the root workspace. The .yarn/sdks/typescript editor SDK stub was intentionally left untouched (it is not a dependency declaration).

Package manager

Yarn 4.5.3 (packageManager: yarn@4.5.3, nodeLinker: node-modules, no committed yarn.lock — it is .gitignored).

What was fixed

1. yarn install was blocked by Yarn's bundled TypeScript compat patch.
Yarn 4.5.3's built-in plugin-compat unconditionally wraps typescript in a patch (builtin<compat/typescript>) that adds Plug'n'Play awareness to the compiler. The patch's embedded diffs assume every TypeScript >=5.7.1 release ships the same lib/_tsc.js layout — an assumption TS7's native package breaks, so yarn install failed with a raw ENOENT before the patch was even applied.

Fixed with a small local Yarn plugin (.yarn/plugins/plugin-skip-typescript-compat-patch.cjs, wired up in .yarnrc.yml) that unwraps the patch via the reduceDependency hook. This is safe regardless of TypeScript version because the repo uses nodeLinker: node-modules, so the patch's PnP awareness was never providing any benefit here.

2. yarn build was blocked by rollup-plugin-typescript2's dependency on the classic TS compiler API.
rollup-plugin-typescript2 (used by the shared rollup.config.mjs for all four JS library packages) drives TS's classic Program/LanguageService API for bundling. TS7's native package doesn't expose that API (tsModule.createDocumentRegistry is not a function).

Fixed by replacing it with rollup-plugin-swc3, which transpiles per-file using swc instead of the classic compiler API. Type-checking and declaration output are unaffected — they're already handled by the tsc -b step that runs before rollup in g:build. This also surfaced two small latent issues, now fixed:

• A mixed type/value re-export in Arc.React.MVVM/messaging/IMessenger.ts (MessageHandler is a type, IMessenger is a value — tsc resolved this via full program type info, but a per-file transpiler can't, so MessageHandler needed an explicit type modifier).
• rxjs wasn't declared external in the shared rollup config; Arc.React bundles transitively import it from Arc's own externalized output, and swc's plugin surfaced the gap as an "unresolved dependency" warning where rollup-plugin-typescript2 had silently swallowed it.

The Arc.Vite/EmitMetadataPlugin.ts rewrite (already in this PR) ports the plugin's per-file decorator-metadata transpile off the TS compiler API onto @swc/core, since TS7's native package doesn't expose ts.transpileModule/ts.sys/config parsing either. Verified manually that it still emits correct Reflect.metadata calls for decorated classes under this toolchain.

3. yarn lint was blocked by @typescript-eslint reading classic TS compiler API surface at module load time.
@typescript-eslint's parser (and its own dependency ts-api-utils) reads things like ts.Extension, ts.sys, and ts.SyntaxKind as soon as they're required — not just when type-aware linting is used. TS7's native package doesn't expose any of it. @typescript-eslint has no TS7-compatible release yet, even on its current canary channel, and Yarn's peer-dependency resolution won't route a fix around it: typescript is a peerDependency throughout the @typescript-eslint family, and neither resolutions nor packageExtensions can override a peer dependency that's already declared — they only ever add one that's missing — so the mismatched, hoisted root TypeScript always won regardless of how the override was written.

Fixed by adding typescript-for-eslint as an aliased devDependency (a real TypeScript 6.0.3 install, within @typescript-eslint's supported peer range) and a postinstall script (link-eslint-typescript.js) that walks @typescript-eslint's real, Node-resolved dependency tree and copies that alias into the node_modules of every package in it that itself depends on typescript. Node's module resolution then finds that copy before it would reach the hoisted TypeScript 7, without touching how the rest of the build resolves typescript.

Verification: fresh yarn install → yarn ci (clean → lint → build → test, zero errors/warnings, all specs pass across all 4 packages) → tsc -b (zero errors) → dotnet clean && dotnet build -c Release (zero warnings, zero errors, including TypeScript proxy generation in the TestApps).

Workflows

No workflow changes needed. .github/workflows/javascript-build.yml only runs yarn + yarn ci (no TS version pin) and now passes end to end. codeql.yml references the CodeQL language keyword javascript-typescript, which is unrelated to the compiler version. No workflow pins a TypeScript version or installs tsc directly.

🤖 Generated with Claude Code