fix(ci): unblock releases from TypeScript 7 - #19
Merged
Conversation
The release preflight runs the TypeScript compatibility check, so this has been blocking every release, whatever its contents, since TypeScript 7 became `latest`. Two things broke, in sequence. Yarn 4.9.1 could not install TypeScript 7 at all: it applies a builtin compatibility patch to the package, and that patch cannot be applied to a TypeScript this new, so `yarn add` failed inside `patchPackage` before any type checking happened. Yarn 4.17.1 installs it cleanly. Past that, the check itself was asking for a configuration that no longer exists. TypeScript 7 removed `target: es5` and `moduleResolution: node10`, the two options the test app's tsconfig is built on — so the three checks that run against `latest` were compiling our type definitions under a setup nobody on a current TypeScript can have. They now override those two options with what such a consumer uses instead, at the oldest target still available, which keeps what the older pinned checks are there to prove. `ignoreDeprecations: '6.0'` goes with them: the options it silenced are gone rather than deprecated, so it no longer has anything to do. The lockfile bump is yarn writing its current format, and the ignore entry is for a file yarn writes into the test apps by itself.
`yarn install --immutable`, which every CI job starts with, refuses an install that would rewrite the lockfile — and the new yarn rewrites this one: it bumps the format version and re-hashes the builtin `resolve` patch. Missed on the first pass because building and testing locally reuses an existing `node_modules` and never re-runs the install the way CI does.
Running the new yarn rewrote `.yarnrc.yml` on its own: it dropped the comment explaining why the global cache is off, and added `approvedGitRepositories: "**"`, `enableScripts: true` and `npmMinimalAgeGate: 0` — the last two of which turn off a supply chain protection and let any git host serve a dependency. None of it belongs in a toolchain upgrade, and none of it is needed: `yarn install --immutable` and all six compatibility checks pass with the file as it was, plus the new yarn path. The ignore entry goes with them. The file it covered is written into the test apps by yarn only when the settings above are set at the root, so with those gone nothing generates it, and ignoring it would only have hidden them coming back.
Yarn 4.17 stopped running them by default, where 4.9 ran them, and the e2e suite depends on one: puppeteer fetches the Chrome it drives from its own install script. Without it the suite fails on every run looking for a browser nothing ever downloaded. Restoring it keeps the upgrade to the toolchain. Leaving scripts off is a worthwhile change on its own, but it needs the browser fetched some other way first, and that is not this.
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
1 participant
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.
Why this is blocking
deploy-auto.yml's release preflight runsyarn test:compat:tsc, and that check is red — so every release is blocked right now, whatever its contents. A re-release ofv0.0.6would fail the same way.It is not caused by anything in
#18, and not by our type definitions:#18touched undertest/,scripts/,yarn.lock,.yarnrc.yml, rootpackage.jsontest/apps/vanillatree hash,v0.0.6vspublishfaccbb67)test/apps/vanilla/tsconfig.json, none in any.d.tsThe trigger is time, not a commit:
typescript@latestis now 7.0.2, where it was 5.x when this last went green.What broke, in order
1. Yarn could not install it. Yarn applies a builtin compatibility patch to the
typescriptpackage, and 4.9.1's cannot be applied to TypeScript 7 —yarn add --dev typescript@latestfailed insidepatchPackagebefore any type checking ran.2. The check asked for a configuration that no longer exists. TypeScript 7 removed
target: es5andmoduleResolution: node10, the two options the test app's tsconfig is built on:So the three checks that run against
latestwere compiling our definitions under a setup no consumer on a current TypeScript can have.The change
Yarn 4.9.1 → 4.17.1, which is what upstream is on, and which installs TypeScript 7 cleanly.
The
latestchecks now override the two removed options with what such a consumer uses instead —target: es2015,module: preserve,moduleResolution: bundler— which is also what this test app already is, a bundler-resolved web app.es2015is the oldest target TypeScript 7 still accepts, so they keep proving what the older pinned checks prove: that the definitions survive a low target. The pinned 3.8.2 and 4.1.6 checks keep the existing tsconfig untouched; that configuration is exactly what they exist to verify.ignoreDeprecations: '6.0'is dropped — the options it silenced are removed rather than deprecated, so it no longer does anything. Verified by running without it.What the upgrade dragged in
Two things the new yarn changes underneath, both handled deliberately rather than by accepting what it wrote:
Lockfile format. Yarn 4.17 writes format 10 and re-hashes the builtin
resolvepatch.yarn install --immutable, which every CI job starts with, refuses an install that would rewrite the lockfile, so both lockfiles are migrated here.Install scripts are now off by default, where 4.9 ran them. The e2e suite depends on one: puppeteer fetches the Chrome it drives from its own install script, and without it the suite fails looking for a browser nothing downloaded.
enableScripts: truerestores the behaviour the repository already had. Leaving scripts off is a worthwhile change on its own — it needs the browser fetched another way first, and that is not this.Running the new yarn also rewrote
.yarnrc.ymlby itself: it dropped the comment explaining why the global cache is off, and addedapprovedGitRepositories: "**"andnpmMinimalAgeGate: 0, which turn off a supply chain protection and let any git host serve a dependency. None of that is in this branch — CI installs cleanly without it, so a toolchain upgrade is not the place to quietly relax either.Verified
CI green on all five jobs. Locally, the whole release preflight:
yarn install --immutable·yarn build·yarn lint·node scripts/check-packages.js·yarn typecheck·yarn test:unit(2682) ·yarn test:compat:tsc(all six checks) ·yarn test:compat:ssr.Noted, not fixed
check-typescript-compatibility.jsrunsyarn addoutside thetry, so an install failure skipsrestoreFilesand leaves the test app mutated — which is what made this awkward to diagnose.npmMinimalAgeGatenow defaults to 24 hours. The compatibility check installstypescript@latest, so it will fail for a day after each TypeScript release until that is handled.