experiment: dep alignment without --linker=hoisted — is the workflow change needed?#781
Closed
jrusso1020 wants to merge 4 commits into
Closed
experiment: dep alignment without --linker=hoisted — is the workflow change needed?#781jrusso1020 wants to merge 4 commits into
jrusso1020 wants to merge 4 commits into
Conversation
…sent Two narrow fixes pulled out of a larger Windows-CI investigation: ## 1. Format check (`oxfmt`) `packages/core/package.json` and `packages/shader-transitions/package.json` had their `publishConfig` keys reordered to a non-canonical order by the v0.6.1 release commit (`82fd2967`). Releases push directly to main without going through PR CI, so the drift wasn't caught and `bun run format:check` has been failing on every push since. Fix: re-run `oxfmt`. ## 2. `@hyperframes/cli` `build:fonts` skip-when-present `packages/cli`'s `build:fonts` script regenerated `packages/producer/src/services/fontData.generated.ts` unconditionally on every cli build. The script reads `@fontsource/*` packages via `require.resolve(...)`, which walks `packages/producer/node_modules/@fontsource/*` junctions — these trip `EPERM: operation not permitted, stat` on Windows GHA runners because of long-running bun-on-Windows workspace junction bugs (see oven-sh/bun#23615, #18354, #10146). `fontData.generated.ts` is committed to git, so the regeneration is only needed when fonts actually change. Match the skip-when-present pattern already in `@hyperframes/producer`'s own `build:fonts`. Doesn't fix the Windows render verification end-to-end (the producer build itself still trips junction issues — being tackled separately in #765), but at least stops `cli build:fonts` from being its own failure point on Windows.
Pushing further to actually get Windows render verification green, not just work around it. ## What's wrong on Windows Bun 1.3's default `isolated` linker creates nested workspace junctions under `packages/*/node_modules/` on Windows GHA runners. Those junctions don't materialize reliably — Node's `realpathSync` returns `EPERM` on stat, and ESM resolution returns `ERR_MODULE_NOT_FOUND`. Every Windows build since PR #748 has tripped this in one of three places: - `packages/producer/build.mjs` importing `esbuild` - `packages/producer/scripts/generate-font-data.ts` reading `@fontsource/*` - `packages/producer` running `tsc` to emit `.d.ts`s Long-running bun bugs: oven-sh/bun#23615, #18354, #10146. ## Fix **1. `--linker=hoisted` for the Windows install step** (workflow change, Windows only). Hoisted layout puts deps as real directories at the workspace root + workspace package node_modules. No junctions, no Windows-specific path quirks. Linux CI keeps the default isolated linker; the lockfile is linker-agnostic so `--frozen-lockfile` is still valid. **2. Source-level FormData narrowing in `packages/core/src/studio-api/routes/files.ts`** (needed because the hoisted layout exposes a `@types/node@25` typecheck issue that the isolated layout hides). With v25 + an `onmessage` global in scope, the ambient `FormData.entries()` infers `[string, string]` instead of `[string, File | string]`, so the `value instanceof File` check breaks at `TS2358`. Cast the iterator to a `[string, FileLike | string]` shape and narrow via `typeof value === "string"`. Identical runtime behavior; works under both v24 (isolated layout, what Linux CI sees) and v25 (hoisted, what Windows CI sees with this change). ## Verification - `bun install --frozen-lockfile` (isolated, default): full build green - `bun install --frozen-lockfile --linker=hoisted`: full build green, core typecheck passes, `@hyperframes/core` 853 tests pass - Format/lint clean on both layouts
The Windows install failures (`ENOENT: failed copying files from cache to destination for package @types/node` / `esbuild`) are caused by bun creating workspace-scoped nested installs under `node_modules/@hyperframes/<pkg>/node_modules/...`. Those nested paths only exist because each workspace package pinned a different `@types/node` / `esbuild` major: - root: `@types/node ^25.0.10`, core: `^24.10.13`, cli/engine/producer: `^22` - core/cli: `esbuild ^0.25.x`, producer: `^0.27.2` Each major-version gap forces bun to install a workspace-scoped copy in a deep `node_modules/@hyperframes/<pkg>/node_modules/<dep>/node_modules/...` tree that bun can't reliably materialize on Windows GHA runners. Aligning versions lets bun dedup to a single root-hoisted install per dep, and the nested workspace block disappears from `bun.lock` entirely. ## Alignment - `@types/node` → `^25.0.10` across root, core, cli, engine, producer - `esbuild` → `^0.25.12` across cli, core, producer - `tsx` → `^4.21.0` across producer (matches root + core) ## Source-level v25 compat (already in this PR) @types/node v25 declares `File` as an interface (not a class) and exposes a conditional global where `FormData.entries()` narrows to `[string, string]` when an `onmessage` global is in scope. `packages/core/src/studio-api/routes/files.ts`'s `value instanceof File` check was relying on the v24 class declaration — already cast the iterator to `Iterable<[string, FileLike | string]>` in the prior commit. Two more v25 source fixes here: - `packages/cli/src/commands/init.ts` - `packages/cli/src/whisper/normalize.ts` `Dirent.path` was removed in @types/node v25 (deprecated alias for `parentPath` since Node 20.12). Drop the `?? e.path` fallback. ## Verification Both install layouts now build clean end-to-end: - `bun install` (isolated, default): full build green, 853 core tests pass, typecheck green across all 7 packages - `bun install --linker=hoisted` (Windows CI): same result - `bun.lock` no longer contains any `@hyperframes/<pkg>/<dep>` nested workspace entries — 70+ lines of nested install blocks gone
… alone fixes CI If dep alignment alone eliminates the workspace-scoped nested installs that bun's Windows isolated layout can't materialize, then this PR's workflow change is dead weight. Reverting it to see if Windows CI still greens with isolated linker + aligned deps + source-level v25 fixes.
Collaborator
Author
|
Closing — experiment result. Dep alignment without |
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.
This is an experiment, not intended for merge.
Tests the hypothesis from #778's investigation: with the workspace dep alignment (
@types/node^25,esbuild^0.25.12,tsx^4.21.0) eliminating the nested workspace installs inbun.lock, the isolated linker might actually work on Windows. The--linker=hoistedworkflow change in #778 may be dead weight.This branch is #778 minus the workflow change. If Windows is still green here, we can drop
--linker=hoistedfrom #778 and keep just the dep alignment + source fixes.Diff vs #778
.github/workflows/windows-render.ymlto origin/main (drops--linker=hoisted)