fix(deploy): make main deployable again after the contract package landed #575

Merged
gmackie merged 1 commit from fix/deploy-after-contract-package into main 2026-09-14 05:21:20 +00:00
Owner

#574 fixed the Corepack hang, and its deploy got straight past that step, then failed on two things #564 broke that CI doesn't exercise. Production is still serving the 2026-09-09 build; #564, #567 and #571 are merged but unshipped.

1. Web build — webpack can't resolve .js imports in @forgegraph/contract

../../packages/contract/src/ir/index.ts
Module not found: Can't resolve '../canonical.js'
Import trace: ./src/app/api/fg/contracts/route.ts

The contract package imports its siblings as ./x.js. Its tsc ESM output needs that, and TypeScript maps it back to ./x.ts. The web app compiles the package from source (its workspace exports point at src/), and webpack doesn't make that mapping. The fix is resolve.extensionAlias in next.config.ts.

Why this can't change anything else:

  • apps/web's own source has zero relative .js imports.
  • check-events (74) and worker-budget (1) use the same pattern but aren't imported by web code — which is why they never broke.

2. Registry build — stale pnpmDeps hash

flake.nix pins the registry's fixed-output hash over the whole repo, and #564 moved pnpm-lock.yaml, so every registry redeploy fails with hash mismatch in fixed-output derivation. The value here is the got: the agent reported on hetzner-fg for fbeca202, exactly as the flake comment instructs. This PR doesn't touch the lockfile, so it stays valid. (The running registry is unaffected: it's on the gcrooted l3y43xaw build.)

Verified

On a fresh install at fbeca202, next build --webpack fails with the same two errors as the deploy, and succeeds with the alias (216 pages).

How it got through

CI runs typecheck, lint, unit tests and the Storybook build, but never next build for apps/web. A build step would have caught this; it wasn't added here because it costs runner time and memory on tight runners.

🤖 Generated with Claude Code

#574 fixed the Corepack hang, and its deploy got straight past that step, then failed on two things #564 broke that CI doesn't exercise. **Production is still serving the 2026-09-09 build; #564, #567 and #571 are merged but unshipped.** ## 1. Web build — webpack can't resolve `.js` imports in `@forgegraph/contract` ``` ../../packages/contract/src/ir/index.ts Module not found: Can't resolve '../canonical.js' Import trace: ./src/app/api/fg/contracts/route.ts ``` The contract package imports its siblings as `./x.js`. Its `tsc` ESM output needs that, and TypeScript maps it back to `./x.ts`. The web app compiles the package **from source** (its workspace `exports` point at `src/`), and webpack doesn't make that mapping. The fix is `resolve.extensionAlias` in `next.config.ts`. Why this can't change anything else: - `apps/web`'s own source has **zero** relative `.js` imports. - `check-events` (74) and `worker-budget` (1) use the same pattern but aren't imported by web code — which is why they never broke. ## 2. Registry build — stale `pnpmDeps` hash `flake.nix` pins the registry's fixed-output hash over the whole repo, and #564 moved `pnpm-lock.yaml`, so every registry redeploy fails with `hash mismatch in fixed-output derivation`. The value here is the `got:` the agent reported on hetzner-fg for `fbeca202`, exactly as the flake comment instructs. This PR doesn't touch the lockfile, so it stays valid. (The running registry is unaffected: it's on the gcrooted `l3y43xaw` build.) ## Verified On a fresh install at `fbeca202`, `next build --webpack` fails with the same two errors as the deploy, and **succeeds with the alias (216 pages)**. ## How it got through CI runs typecheck, lint, unit tests and the Storybook build, but **never `next build` for `apps/web`**. A build step would have caught this; it wasn't added here because it costs runner time and memory on tight runners. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
fix(deploy): make main deployable again after the contract package landed
All checks were successful
CI / gitleaks (pull_request) Successful in 6s
CI / storybook (pull_request) Successful in 1m37s
forgegraph/ci CI passed
CI / ci (pull_request) Successful in 11m46s
caf1da4314
Two things #564 broke that CI does not exercise, both now blocking every
self-deploy on main (prod is still serving the 2026-09-09 build; #564,
#567 and #571 are merged but unshipped).

1. The web build. @forgegraph/contract imports its siblings as `./x.js`,
   which its tsc ESM output needs and TypeScript maps back to `./x.ts`.
   The web app compiles that package from source, and webpack does not make
   that mapping, so `next build --webpack` fails:
     packages/contract/src/ir/index.ts
     Module not found: Can't resolve '../canonical.js'
   Teach webpack the same mapping with resolve.extensionAlias. The web app's
   own source has no relative `.js` imports, so nothing else it resolves
   changes. CI runs typecheck, lint, unit tests and the storybook build but
   never `next build` for apps/web, which is how this merged green.

2. The registry build. flake.nix pins the registry's pnpmDeps fixed-output
   hash, and #564 moved pnpm-lock.yaml, so every registry redeploy fails with
   "hash mismatch in fixed-output derivation". Paste the `got:` value the
   agent reported on hetzner-fg for fbeca202, as the flake comment says to.
   This change does not touch the lockfile, so the value stays valid.

Verified locally on a fresh install at fbeca202: the build fails exactly as
the deploy did without the alias, and succeeds with it (216 pages).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Author
Owner

Preview environment is live: https://pr-575-forgegraph.forgegraf.com

Deployed caf1da43 with the beta stage's environment. It redeploys on every push and is destroyed when this PR closes.

Preview environment is live: https://pr-575-forgegraph.forgegraf.com Deployed `caf1da43` with the beta stage's environment. It redeploys on every push and is destroyed when this PR closes.
gmackie scheduled this pull request to auto merge when all checks succeed 2026-09-14 05:16:01 +00:00
gmackie canceled auto merging this pull request when all checks succeed 2026-09-14 05:21:16 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
gmackie/ForgeGraph!575
No description provided.