fix(ci): build the SDK types with the repo's own tsc (and pin the pantry action) - #104
Open
glennmichael123 wants to merge 3 commits into
Open
fix(ci): build the SDK types with the repo's own tsc (and pin the pantry action)#104glennmichael123 wants to merge 3 commits into
glennmichael123 wants to merge 3 commits into
Conversation
`integration` has been red on main since this morning on commits that changed no dependency file — b693fb0 and 14fe431 both fail, 69e01f5 passed. Nothing in the repo changed; the action did. `pantry-pm/pantry/packages/action` was referenced as `@main`, so every run resolved it fresh. The last green run took SHA 235036fa; the first red one took 88dd705e. The typescript that SHA provisions cannot resolve its own `@typescript/typescript-linux-x64` binary, so `bun run tsc` dies: Error: Unable to resolve @typescript/typescript-linux-x64. Either your platform is unsupported, or you are missing the package on disk. Only `integration` runs `bun run build` in packages/typescript, and that is the only script that reaches `tsc` — `typescript-sdk` runs typecheck and tests, `lint` runs pickier. That is why one job went red and the rest stayed green, which reads like a code problem and is not one. Pinned to 235036fa everywhere it is referenced, not just in ci.yml: the same floating ref is in release, benchmarks, binary-size, mobile-e2e and native-lifecycle, and a publish workflow that resolves a different action on every tag is the version of this bug that is expensive to find.
✅ Binary Size Report
Size limits
|
✅ Binary load timeWhat this measures
Both binaries are measured interleaved on this runner and compared by |
…PATH Pinning the pantry action was not enough, and the run that proved it is the useful part: the pin took effect — the log shows `pantry-pm/pantry@235036fa…` — and `integration` failed identically. Pinning the action pins the *installer*, not what it installs. The same run shows it fetching `[email protected]`, resolved fresh at runtime, and that dev build cannot resolve its own `@typescript/typescript-linux-x64`. Any pin of the action would have left that untouched. The actual defect is that craft built with whatever `tsc` happened to be first on PATH. `bun run tsc` finds the repo's own `[email protected]` locally, because nothing shadows `node_modules/.bin`; in CI the action installs into `<repo>/pantry` and puts it ahead, so the same script silently ran a different compiler. A repo should build with the toolchain it declares. `bunx --bun tsc` resolves the local one in both places. It is also the form CLAUDE.md already prescribes for pickier, so the two agree now. The action pin stays. It did not fix this, and the commit before this one said it would — but a third-party action referenced as `@main` is worth pinning for its own sake, and `release.yml` resolving a different action on every tag is the version of that risk that costs the most to discover.
glennmichael123
changed the title
…iglang.org still serves
Two CI failures, one commit, because the second only became visible while
fixing the first.
**integration.** The earlier commit here routed `build:types` through
`bunx --bun tsc` and claimed that fixed it. It did not, and the run that
proved it is worth reading: `build:types` was never reached, because
`build.ts` itself calls `bunx tsc` twice (lines 28–29) and dies first. Both
resolve through PATH, and the pantry action in CI provisions its own
typescript into `<repo>/pantry` ahead of `node_modules/.bin` — a dev build
the lockfile never pinned, whose linux-x64 platform binary is missing.
Locally nothing shadows `node_modules/.bin`, which is why the same command
worked here and failed there.
`scripts/tsc.ts` resolves `typescript` through the module graph and execs
its `bin/tsc`. `build.ts` and `build:types` both go through it now, so
every place craft runs the compiler runs the one `bun.lock` names.
**darwin-x64.** `Setup Pantry` failed with
HTTP 404 downloading https://ziglang.org/builds/zig-x86_64-macos-0.17.0-dev.1509+bb296ab9b.tar.xz
and every other platform's 1509 tarball 404s too. ziglang.org's index lists
one dev build — current master — plus tagged releases; the rest are pruned.
The three legs that passed did so on cached toolchains, and the next tagged
release would have failed to provision the same way. `deps.yaml` moves to
1963 and its comment records the shelf life, which the pin's existing
comment did not know about.
The drift was one idiom: 27 hand-rolled `.{ .items = &.{}, .capacity = 0 }`
list inits, which 1963 rejects because `ArrayList` gained a field. `.empty`
exists on both toolchains and the tree already uses it 193 times.
Verified on 1963: `zig build test` 150/150 steps, 0 failures;
`build-ios-all` all three archives; `zig build -Djs-runtime=false` clean.
`packages/typescript`: `bun run build` emits both `.d.ts` files, 512 tests
pass, pickier clean.
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.
integrationhas been red onmainsince this morning, on commits that changed no dependency file.69e01f5(v0.0.87, 00:37)b693fb0(#102, 12:23)14fe431(#101, 12:38)git diff 69e01f5..b693fb0 -- '*package.json' '*bun.lock*' '*bunfig.toml'is empty. Nothing in the repo changed.The wrong diagnosis, and what disproved it
My first commit here assumed the cause was
pantry-pm/pantry/packages/action@main— a floating ref that moved from235036fa(green) to88dd705e(red) — and pinned it. That did not fix it. The run is worth reading: the pin took effect, the log showsDownload action repository 'pantry-pm/pantry@235036fa…', andintegrationfailed identically.Pinning the action pins the installer, not what it installs. The same run shows it fetching:
resolved fresh at runtime. That dev build cannot resolve its own platform binary:
No pin of the action would have changed that.
The actual defect
craft builds with whatever
tscis first on PATH.packages/typescript'sbuild:typesranbun run tsc. Locally that finds the repo's own[email protected], because nothing shadowsnode_modules/.bin. In CI the pantry action installs into<repo>/pantryand puts it ahead on PATH, so the identical script silently ran a different compiler — a dev build the repo never declared.That also explains why exactly one job went red:
integrationis the only job that runsbun run buildinpackages/typescript, andbuild→build:typesis the only script that reachestscat all.typescript-sdkrunstypecheckandbun test;lintruns pickier. A toolchain break surfaced in one job and looked like a code problem.The fix
bunx --bun tsc, which resolves the local one in both places — and is the form CLAUDE.md already prescribes for pickier, so the two agree now.Verified locally:
bun run buildinpackages/typescriptcompletes and emits bothdist/index.d.tsanddist/index.d.cts.The pin stays
It did not fix this, and the commit that added it claimed it would. But a third-party action referenced as
@mainis worth pinning for its own sake, andrelease.ymlresolving a different action on every tag is the version of that risk that costs the most to discover. All 15 references are pinned; the Apple signing gate inrelease.ymlis untouched — the only lines changed there are threeuses:refs.Unblocks #103.