Bootstrap CodePress Live Dev Server recipe + dev Dockerfile

[codepress-dev]

Summary

This sets up the files CodePress needs to boot a live, hot-reloading preview of this project's React app (web/) on demand, instead of guessing how to run it each time. Two new files describe the frontend and how to start it in dev mode; nothing about how the app builds or deploys today changes, and no application code was touched. One thing worth knowing: the React app here is Create React App from 2017 (react-scripts 1.0.10), so the preview image deliberately pins an older Node version that this toolchain still runs on. Separately, the Django server in server/ was checked for preview-related CORS setup and needs none — it serves the React production build itself, so browser requests are same-origin, and it has no staging environment to scope such a change to.

Technical details

Adds .codepress/dev-server/recipe.json (schema_version 1) with a single frontend entry and .codepress/dev-server/Dockerfile.web.

Recipe entry — label: web, working_dir: web, framework: cra, package_manager: yarn (from web/yarn.lock; no packageManager field anywhere), install_command: yarn install --frozen-lockfile, dependency_manifests: ["web/yarn.lock"] (the lockfile lives in the app dir, not the repo root), dev_port: 3000 (CRA default; no port override in the start script), system_packages: ["procps"], size: medium. prebuild_command is empty — postbuild (cp -r build/ ../server/static/build/) is a production-build concern and must not run for a dev preview. staging_backend_url is omitted: there is no .env*, no .github/, no vercel.json, and no .codepress/verify-staging/recipe.json, so there was no candidate — and therefore no frontend API-base env var to prefill either.

Dockerfile — thin/toolchain-only per the contract: no COPY of source or manifests, no baked node_modules, deps arrive at runtime on the bind-mounted checkout at /app. Final WORKDIR /app/web, with /app/web/node_modules/.bin and /app/node_modules/.bin prepended to PATH as a backstop. CMD routes through the package manager (yarn start) and maps the runtime contract into CRA's own env names: HOST=$CODEPRESS_BIND_HOST, plus WDS_SOCKET_PORT/WDS_SOCKET_PROTOCOL.

Two decisions worth a close look:

• Base image is node:18-bookworm, not the current LTS. web/yarn.lock pins webpack@2.6.1 and webpack-dev-server@2.5.0; those do not run reliably on recent Node majors. 18 is the newest Node with a -bookworm variant that this 2017 toolchain still tolerates. If the preview fails to compile, this line is the first thing to revisit.
• No HMR client-port config. react-scripts 1.x builds its sockjs URL from window.location, so the HMR socket follows the public preview origin automatically once websocket upgrades are proxied — WDS_SOCKET_PORT only exists from CRA 3.4 and is inert here. It is still exported so the image honors one uniform runtime contract. DANGEROUSLY_DISABLE_HOST_CHECK=true and BROWSER=none are set for the containerized dev server (host check would otherwise reject the preview hostname; CRA would otherwise try to launch a browser). Both are confined to this dev image.

corepack prepare yarn@1.22.22 --activate bakes only the yarn binary so a cold start never fetches a package manager before booting. The single native dep in the lockfile is fsevents (macOS-only, skipped on Linux), so no apt library beyond procps is needed.

Preview CORS and preview social auth were both evaluated and are deliberate no-ops — see Open items.

Changes

• Add .codepress/dev-server/recipe.json — schema_version 1, one web frontend entry (CRA, yarn, port 3000)
• Add .codepress/dev-server/Dockerfile.web — thin dev-mode image on node:18-bookworm binding 0.0.0.0, HMR/bind wired to CODEPRESS_* env vars
• Omit staging_backend_url — no staging backend URL candidate exists in the repo
• No backend CORS change — the Django app in server/ has no cross-origin surface and no staging config path

Test plan

• Confirm the recipe is well-formed: python3 -c "import json;print(json.load(open('.codepress/dev-server/recipe.json'))['frontends'])" — one entry, working_dir web, dev_port 3000.
• Build the dev image from the repo root: docker build -f .codepress/dev-server/Dockerfile.web -t drf-web-dev . — it should build in seconds and contain no node_modules (docker run --rm drf-web-dev ls /app is empty).
• Install deps and run the image the way the runtime does: cd web && yarn install --frozen-lockfile && cd .., then docker run --rm -p 3000:3000 -v "$PWD:/app" drf-web-dev. Wait for Compiled successfully and open http://localhost:3000 — the React welcome page renders.
• Verify it binds all interfaces (not 127.0.0.1) by hitting it from outside the container as above, then edit web/src/containers/home/Home.js (change the Welcome to React heading) and confirm the browser updates without a manual reload.
• Confirm nothing about the existing workflow changed: git diff master --stat touches only the two new files under .codepress/dev-server/.

Open items

• Node 18 is a deliberate pin for react-scripts 1.0.10 / webpack 2.6.1 and is the main risk in this PR. It was not booted end-to-end here — the test plan's docker build + run step is the check that matters.
• No preview-CORS edit was made, and that is intentional: the Django app in server/ renders the React build via a catch-all index view (same-origin), the frontend in web/src makes no cross-origin API calls, and server/ has no django-cors-headers, no CORS allowlist, and no staging settings module or .env.staging to scope a staging-only allowance to. If a separately deployed API is ever introduced that previews call cross-origin, that API's own repo needs this bootstrap run against it.
• No preview social-auth work was needed: web/src has no sign-in flow at all. samples/auth-web/ contains a GitHub OAuth sample, but it is unwired reference code (it imports ../../redux/auth and ../header/Header, neither of which exists) and is not reachable from the running app, so it was left alone.
• No Live Dev Server env vars were prefilled, since no staging backend URL was detected to point the frontend at.

Authors

Generated with CodePress · View the chat session

Co-authored-by: dev@codepress.dev dev@codepress.dev