Skip to content

fix: web build + dev deploy failing on tsc strict checks#1151

Merged
zbigniewsobiecki merged 1 commit intodevfrom
fix/web-build-tsc-errors
Apr 18, 2026
Merged

fix: web build + dev deploy failing on tsc strict checks#1151
zbigniewsobiecki merged 1 commit intodevfrom
fix/web-build-tsc-errors

Conversation

@zbigniewsobiecki
Copy link
Copy Markdown
Member

Summary

The dev deploy + CI Build frontend step have been failing since PR #1148 (spec 011 merge). Root cause: cd web && npm run build runs tsc -b which is stricter than the root npm run typecheck that my local verification uses. Three classes of errors surfaced on the deploy logs:

1. readonly /** jsdoc */ fieldName pattern (TS7008)

steps/webhook-url-display.tsx + steps/container-pick.tsx had the JSDoc comment between readonly and the field name. Stricter tsc parses this as readonly: any + bare fieldName: string without the readonly modifier. Pre-existing from spec 010/3. Downstream callers couldn't satisfy the broken interface (TS2345 cascade). Fixed by moving JSDoc above readonly.

2. currentUser Zod-enum / type-union drift

pm-wizard-hooks.ts verify-button calls pm.discovery.discover({capability: 'currentUser', …}). The backend type union (DiscoveryCapability in src/pm/types.ts) included 'currentUser' from spec 010/2 but the Zod enum at the tRPC input schema was never updated — so every wizard Verify-button call fails at runtime Zod validation. Fixed by promoting the enum to src/pm/types.ts as DISCOVERY_CAPABILITIES (const array) and deriving both the type union AND the tRPC Zod enum from it. The two can no longer drift structurally.

3. JIRA custom-field shape mismatch

jira/wizard.ts mapped jiraProjectDetails.fields (shape {id, name, custom}) directly to providerCustomFields (shape {id, name, type}). Introduced by me in plan 011/3. Fixed by mapping custom: booleantype: 'custom' | 'standard'.

Why wasn't this caught locally

  • npm run typecheck (root) uses the root tsconfig.json — looser.
  • cd web && npm run build uses web/tsconfig.json — stricter, runs tsc -b.
  • The deploy + CI Build frontend steps run the web tsc. My local verification didn't.

Going forward I'll add cd web && npm run build to my verification checklist, and/or we could make the root pre-commit/pre-push hook also run it.

Test plan

  • New regression test in tests/unit/api/pm-discovery.test.ts: accepts currentUser capability (closes Zod-enum / type-union drift) — pins the root-cause invariant.
  • 13 existing pm-discovery tests continue to pass.
  • Full suite: 8187/8187 (+1 new test, no regressions).
  • npm run lint — clean.
  • npm run typecheck (root) — green.
  • npm run build (root) — green.
  • cd web && npm run build (the production step that was failing) — green for the first time since feat(pm): integration hardening follow-ups + wizard shared-component migration (specs 010 + 011/1-2) #1148.

🤖 Generated with Claude Code

The dev deploy + CI `Build frontend` step have been failing since PR
#1148 (spec 011 merge). Root cause: `cd web && npm run build` runs
`tsc -b` which is stricter than the root `npm run typecheck` I've
been using for local verification. Three classes of errors surfaced:

1. `steps/webhook-url-display.tsx` + `steps/container-pick.tsx` had
   a `readonly /** jsdoc */ fieldName: string` pattern (pre-existing
   from spec 010/3). Stricter tsc parses this as `readonly: any` on
   its own + bare `fieldName: string` without the readonly modifier
   (TS7008). Downstream callers couldn't satisfy the broken interface
   (TS2345). Fixed by moving the JSDoc comment above the `readonly`
   keyword.

2. `pm-wizard-hooks.ts` verify-button flow passes `capability:
   'currentUser'` to `pm.discovery.discover`, but the Zod enum at
   the tRPC input schema was missing `'currentUser'` (pre-existing
   from spec 010/2 — type union was updated but the enum wasn't).
   Every wizard Verify-button call failed at runtime Zod validation.
   Fixed by promoting the enum to `src/pm/types.ts` as
   `DISCOVERY_CAPABILITIES` (const array) and deriving both the
   `DiscoveryCapability` type union and the tRPC Zod enum from it —
   the two can no longer drift.

3. `jira/wizard.ts` mapped `details?.fields` directly to
   `providerCustomFields`, but JIRA's discovery shape is
   `{id, name, custom}` while the shared prop contract expects
   `{id, name, type}` (introduced by me in plan 011/3 / 012/2).
   Fixed by mapping `custom: boolean` → `type: 'custom' | 'standard'`.

Tests:
- New regression in `tests/unit/api/pm-discovery.test.ts`:
  `accepts currentUser capability (closes Zod-enum / type-union drift)`
  pins the root-cause invariant.
- Existing 13 pm-discovery tests continue to pass.
- Full suite: 8187/8187 (+1 vs pre-fix).

Verified: `npm test`, `npm run lint`, `npm run typecheck`,
`npm run build`, `cd web && npm run build` — all green.

Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com>
@zbigniewsobiecki zbigniewsobiecki merged commit 9a6329d into dev Apr 18, 2026
7 checks passed
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 18, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant