build(tsconfig): raise test-program lib to ES2022 across 31 packages - #9512
Merged
Merged
Conversation
The test programs diverged on `lib`: five packages had raised it to ES2022, the rest inherited ES2020 from the root config, so the same idiom (`calls.at(-1)`) type-checked or raised TS2550 purely by which package the file lived in. Only `tsconfig.test.json` files move here. The package SOURCE configs and the root `tsconfig.json` are untouched, so what every package SHIPS still compiles against the ES2020 baseline — this is the pattern `packages/app-shell` already documented in its own test config. Each file keeps its existing DOM set exactly; the only axis changed is ES2020 -> ES2022. Every one of the 31 projects is `noEmit`, so nothing here reaches an artifact. `packages/plugin-timeline/tsconfig.test.json` is deliberately NOT touched: it belongs to another in-flight card. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013VGeMu3p6qEFWR6K6GGLaW
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #8691 — the in-lane half, measured. The maintainer fork the card named is answered below: it dissolves.
What moved
31
packages/*/tsconfig.test.jsonfiles, one axis only:libES2020 to ES2022.tsconfig.jsonis untouched. What every package SHIPS still compiles against the ES2020 baseline, so downlevel support is unchanged and this is not the maintainer's downlevel question.vscode-extension.noEmit: true— measured, not assumed — so nothing here reaches an artifact.tsclibis type-only; vitest never reads these configs. There is no runtime direction to this change.packages/plugin-timeline/tsconfig.test.jsonis deliberately NOT touched; it belongs to another in-flight card and is left exactly as found.The distribution that was actually there
The card described the divergence as binary. It is not. Measured at
af4ff1d1e0with TypeScript's own JSONC reader, and independently confirmed by the repo's owncensus:tsconfig-test-parity— two readers, same answer:39
tsconfig.test.jsonprojects, five distinctlibspellings:libcorefieldsplugin-dashboardplugin-editorreactwhich RESTATE the inherited valueapp-shellcomponentsmobileplugin-listi18nplugin-formtypes— a NARROWING, drops DOM.Iterableplugin-grid,examples/schema-catalogvscode-extension— narrowest, no DOM at all, and extends its own sibling rather than the rootThe split that matters is not "sets
lib" versus "inherits": 13 projects setliband five of those still land on ES2020, restating the inherited value for no effect. Reading the file for the presence of alibkey tells you nothing about which level it compiles at.The
.at(-1)population, re-measuredRe-read at
af4ff1d1e0; the card's figure is from six days earlier.plugin-designer, all comments explaining why the author used index arithmetic instead. A naive file-count reader counts the workaround as an instance of the problem.What it cost — before and after, with controls
Dependency closure built first (43/43 turbo build tasks), because an unbuilt tree makes every program look broken identically.
tsc -p tsconfig.test.jsonfor all 37 package projectsturbo run type-check(CI's own job: source AND test programs)Cost of the raise: zero errors, zero overload-resolution changes, in either direction.
Every zero above carries a control proven able to return non-zero in the same command:
.at(-1)on anumber[]inpermissionsBEFORETS2550, the card's exact signatureapp-shell(already ES2022)permissionsAFTER the raisepermissionsAFTERTS2322turbo run type-checkEvery probe was proven on disk before reading a result, and every leg restored under a trap;
git diff HEADverified empty after each.Gates, all exit 0:
type-check:coverage,check:published-tsconfig-exclude,check:self-import,check:published-dist,check:control-bytes,check-changeset-presence(0 published files moved, so no changeset is owed), and the 4 script suites that pin these configs (77 tests).gates_weakened: NONE. Nothing was lowered, loosened or excluded — raising a test program'slibonly admits more to the checker, for files that are never shipped.Why the divergence was invisible
All 37 test projects were green BEFORE this change, including every ES2020 one holding a real
.at(-1). That is not the ES2020 floor being harmless — it is the receiver beingany. Every surviving call site in an ES2020 project reaches.atthrough anas anymock factory or areadonly any[]annotation, so the checker never sees an array and never applies the floor. The rule only bites when someone types the receiver properly, which is exactly what happened on the card that filed this.So the defect was latent, not absent, and it failed in the most expensive direction: green under vitest, green under
tscuntil the day your value is well-typed.The remainder — the fork dissolves
After this change, nothing requires the root
libto move..at(,Object.hasOwn,.findLast, or class static blocks. The shipped code does not want ES2022.packages/app-shellraised its testliband no other, and its config already documents the reasoning verbatim — raised there "so the package SOURCE keeps compiling against the ES2020 baseline it ships to."The downlevel-support question the card correctly declined to answer is a question this card never needed answered. It can stay closed.
After this lands, two projects remain at ES2020, both deliberately outside this PR's surface:
packages/plugin-timeline(another card's file) andexamples/console-starter(notpackages/*).Known consequence, NOT repaired here
Five
plugin-designertest files carry comments justifying index arithmetic by the ES2020 floor. This change makes those comments false. These are test sources, outside this PR's declared file surface, so they are reported rather than edited.One of the five is already false at HEAD, independently of this PR: it states that
.at()"type-checks nowhere in this repo", which five packages have contradicted since before this card was filed. The control run above compiles that exact idiom inapp-shelltoday.Maintainer speed-read (draft)
改了什么 — 31 个包的测试专用 tsconfig,
lib从 ES2020 抬到 ES2022,只动这一个轴,DOM 集合原样保留。根tsconfig.json一个字节没动。为什么改 — 同一个写法
calls.at(-1)在五个包里能过类型检查,在其余包里报 TS2550,差别只取决于文件恰好放在哪个包。作者只能一个包一个包地撞出来这条规则。风险与代价(含回滚) — 实测代价为零:改动前后 37 个测试程序全绿,CI 自己的
type-check81/81 全绿。测试程序不发布、全部noEmit,发布产物与降级支持不受影响。回滚就是 revert 这一个 commit,无迁移、无数据、无下游。已知副作用一项:plugin-designer五个测试文件里解释「为什么不用.at(-1)」的注释会变成过期描述,已在上面单独列出,未在本 PR 内修改。席位意见 — (留空)
你要做的 — 确认一件事:卡片把「要不要抬根
lib」升级成了维护者决定,而实测结论是这个问题不需要回答 —— 发布代码里.at(出现 0 次,根配置不用动。若认可,这条升级可以就此撤销。Generated by Claude Code