mirror of
https://github.com/0xWheatyz/handler.git
synced 2026-08-30 18:26:25 +00:00
Claude
82183d9bca
src/handler/api/static/ was a committed build artifact: Next's content-hashed chunk names churn on every build, so any two branches touching frontend/ were guaranteed merge conflicts there, PR diffs drowned in generated churn, and a forgotten `npm run export` could silently ship a UI older than its source. - gitignore the export (plus frontend/out and .next were already covered) and remove the 52 tracked files. - Dockerfile grows a `ui` stage (npm ci + npm run build) whose output is copied into the packaged tree before pip install, so the image published by docker.yml always carries a UI built from exactly that commit's source — the frontend build is now effectively part of CI with no new workflow. - .dockerignore excludes frontend artifacts and any stale local export: COPY into src/handler/api/static merges, so a checkout copy must never leak in. - pyproject: hatchling skips VCS-ignored files, so `artifacts` re-includes the export when present; absent it, the wheel builds fine and the API just runs headless (it only mounts static/ when the directory exists). - README documents the two build paths (Docker stage vs `npm run export` for source installs) and the headless fallback. Verified: wheel with the export present ships all 52 files (memory page included); wheel without it builds clean and create_app() skips the UI mount. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WYqkoYPX8NAo1V2KyXr1pk
10 lines
344 B
Plaintext
10 lines
344 B
Plaintext
# Frontend build artifacts — all regenerated by `npm install` / `npm run build`. The
|
|
# static export under src/handler/api/static/ is generated too (gitignored at the repo
|
|
# root): `npm run export` produces it for source installs, and the Docker image builds
|
|
# it in its own node stage.
|
|
/node_modules
|
|
/.next
|
|
/out
|
|
/next-env.d.ts
|
|
*.tsbuildinfo
|