fix: vendor web-shared via git subtree, unblock frontend CI#2
Merged
Conversation
git-subtree-dir: web/ui/src/shared git-subtree-split: a5195d42958310e8d1cbc14a7d5349d30115b251
Previously web/ui/vite.config.ts and tsconfig.app.json resolved
@beacon-shared/* via a path relative to a sibling directory outside
the prism repo:
"@beacon-shared": "../../../web-shared"
That worked on the author's laptop (where the beacon monorepo checkout
sits with all four app repos alongside a web-shared dir) but broke
every CI run, since GitHub runners only check out prism and the
sibling dir doesn't exist. Consequence: ~15 src/api/*.test.tsx files
plus page tests all failed under `npm run test:coverage` because the
whole module graph couldn't resolve.
Vendors web-shared into prism's tree at web/ui/src/shared/ via
`git subtree add --prefix=web/ui/src/shared
https://github.com/beacon-stack/web-shared.git main --squash` (the
parent commit on this branch), then rewires the Vite alias and the
tsconfig path map to point at the vendored copy.
No import changes in any prism source file — every existing
`import X from "@beacon-shared/Y"` still resolves correctly.
Same architectural reasoning as pilot's parallel PR: subtree over
published npm package because web-shared ships .tsx source not
compiled JS, a real package needs build/exports/peerDeps, and the
React singleton hack gets harder when the dep is installed via npm
instead of aliased in-tree. Graduate to a published package when a
fourth consumer joins, web-shared needs a React-coupled transitive
dep, two consumers need the same component to behave differently,
or a non-Beacon project wants to consume it. None are true today.
Verified: `npm run build` succeeds, `npm run test:coverage` passes
267 tests with 0 failures.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
prism's integration tests (internal/api/v1/*_test.go via
internal/testutil/db.go) connect to a real Postgres database to
create per-test schemas. Locally they work because the author runs
Postgres on 5432. On CI they silently fell through to the default
DSN and failed on every integration-test package with:
dial tcp 127.0.0.1:5432: connect: connection refused
Adds a postgres:17-alpine service container to the test job with
trust auth, user=runner, database=prism_test, and a health check so
the go test step only fires once Postgres is ready. Also sets
PRISM_TEST_DSN so testutil/db.go picks up the service DSN explicitly
instead of falling through to its localhost default.
Note: the non-test CI jobs (lint, build, docker) don't need the
database, so the service is scoped to the test job only.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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.
Summary
Unblocks prism's frontend test job which was failing in CI across ~15 `src/api/*.test.tsx` files and several page-level tests, all because the whole module graph couldn't resolve:
```
Failed to resolve import "@beacon-shared/..."
```
Same structural issue as pilot's parallel PR — a sibling-directory path alias that resolved locally but not on GitHub runners.
What this PR does
Zero import changes. Every existing `import X from "@beacon-shared/Y"` resolves unchanged.
Why subtree over a published package
Same reasoning as pilot's parallel PR — see Beacon-Stack/pilot#2 for the full rationale and the devil's advocate / architect decision trail. Short version: `web-shared` ships `.tsx` source not compiled JS, a real package needs a build step + `exports` map + `peerDependencies`, and the existing React singleton hack gets harder when the dep resolves via `node_modules` instead of an alias.
Verification
```
cd web/ui
npm run build # ✓ builds cleanly, 2.49s
npm run test:coverage # ✓ 267 passed, 23 skipped, 0 failed, 898ms
```
Test plan