fix(front): remove the duplicate API_BASE declaration that breaks the build - #121
Merged
Conversation
… build Merging #115 (WO-01, the NEXT_PUBLIC_API_URL -> NEXT_PUBLIC_API_BASE_URL rename) and #119 (WO-11) kept both sides of the collision in api.ts, so main declares const API_BASE twice. tsc reports TS2451 twice, `next build` fails outright, and three test files no longer parse. The frontend cannot be built or deployed from main. Keep the renamed variable, which is the whole point of WO-01: the deployed frontend was talking to localhost because it read the wrong env var name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
7 tasks
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
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.
What
maindeclaresconst API_BASEtwice, atfrontend/src/lib/api.ts:78and:79:This removes the first one. The renamed variable is the one to keep — it is the entire point of WO-01 (#82): the deployed frontend was talking to
localhostbecause it read the wrong env var name.Why
The frontend cannot be built or deployed from
mainright now.npx next buildfails outrighttscreports TS2451 twiceverify.test.ts,style-profiles.test.ts,StyleDnaPanel.test.tsHow this got in
Merging #115 (WO-01) and #119 (WO-11) — two independent branches that both touch
frontend/src/lib/api.ts— kept both sides of the collision instead of choosing one.Worth noting for the process, not for blame: each PR passed Frontend lint + typecheck on its own head. Neither was ever typechecked against the other's result, because that combination only came into existence at merge time. A conflict resolved by keeping both sides produces valid-looking diff hunks and invalid TypeScript, and nothing in the pipeline looked at the merged tree before it landed on
main.If branch protection can require "branches must be up to date before merging", that closes this class of failure for the remaining PRs.
How IBM Bob helped
Found by a Claude Code agent working on #44, which hit the broken build while trying to launch the app to click through its own feature. It reported and stopped rather than fixing it as a side quest, per the dispatch protocol — the same rule that produced #99, #100, #102 and #107.
Screenshots / output
One declaration, using the renamed variable. The Frontend lint + typecheck job on this PR is the real verification.
Checklist
make test)make lint)docs/.env.exampledocs/api_contract.yamlREADME.mdupdated