Bootstrap CodePress Live Dev Server recipe + dev Dockerfile

[codepress-dev]

Summary

This sets up the Live Dev Server for django-react-intro so that CodePress previews of this repo boot the React app from files that live in the repo, instead of CodePress guessing how to start it at runtime. The result: when someone opens a preview for a branch of this repo, the web/ create-react-app dev server starts with hot reloading and is reachable at the preview URL, with no per-session setup. The two new files are configuration only — they change nothing about how the app builds, runs locally, or deploys today, and re-running the bootstrap can safely regenerate them.

Technical details

Discovery found exactly one runnable frontend and no CORS surface to configure.

.codepress/dev-server/recipe.json — schema_version: 1 with a single frontends[] entry for web/: framework: cra (react-scripts 1.0.10), package_manager: yarn (web/yarn.lock is a v1 lockfile; no packageManager field anywhere), install_command: yarn install --frozen-lockfile, dependency_manifests: ["web/yarn.lock"], dev_port: 3000, system_packages: ["procps"], size: medium. prebuild_command is empty — the start script is a bare react-scripts start with no build prefix, and postbuild (copying build/ into the Django static dir) is production-only.

.codepress/dev-server/Dockerfile.web — a thin, toolchain-only dev image: no baked node_modules, no source COPY; deps are hydrated at runtime onto the bind-mounted checkout at /app. Notable decisions:

• Base node:18-bookworm (full, from the ECR-public mirror — verified the tag resolves there). Nothing in the repo pins a Node version, so rather than the latest LTS I picked the newest line a 2017-era CRA/webpack-2 toolchain is comfortable on. I checked the published react-scripts@1.0.10 and webpack@2.6.1 tarballs: webpack 2's default output.hashFunction is md5, not md4, so the usual ERR_OSSL_EVP_UNSUPPORTED / --openssl-legacy-provider workaround is not needed here and is deliberately absent.
• DANGEROUSLY_DISABLE_HOST_CHECK=true in the CMD. This is the one non-obvious line worth a look. webpack-dev-server 2.5.0 ships the DNS-rebinding host check, which would answer the proxied preview hostname with Invalid Host header. I verified against the 1.0.10 tarball that config/webpackDevServer.config.js honors this env var (disableHostCheck: !proxy || process.env.DANGEROUSLY_DISABLE_HOST_CHECK === 'true'), so it is supported on this exact version — it is the CRA analogue of Vite's server.allowedHosts.
• HMR needs no code change. react-dev-utils@3.x's webpackHotDevClient builds its SockJS URL from window.location (confirmed in the tarball), so the HMR socket rides the preview origin over wss:443 automatically. WDS_SOCKET_PORT is wired from CODEPRESS_HMR_CLIENT_PORT for the uniform runtime contract even though react-scripts 1.x ignores it — no repo config file was touched.
• Bind is HOST="$CODEPRESS_BIND_HOST" (default 0.0.0.0), PORT from the runtime, BROWSER=none. Yarn 1.22.22 is pinned via corepack prepare so a cold start never downloads a package manager. procps is the only apt package: the sole native module in the lockfile is fsevents (darwin-only, skipped on linux), so nothing compiles against a system library.

Staging backend URL: omitted, not guessed. There is no .codepress/verify-staging/recipe.json, no .env*, no vercel.json, no framework rewrites and no .github/workflows/ in the repo — zero candidates, so staging_backend_url is absent rather than invented, and no Live Dev Server env var was prefilled.

Preview CORS: correctly a no-op. The Django project in server/ fails both cross-origin gates — it has no CORS surface at all (no corsheaders in INSTALLED_APPS/MIDDLEWARE, no CORS_* settings), and there is no cross-origin caller: web/src makes zero API calls and defines no API base URL, while the deploy model is same-origin (postbuild copies the CRA build into server/static/build and urls.py catch-alls to a template render). Separately, the project has no staging environment to scope an allowance to — one settings.py with DEBUG = True, no settings package. So nothing was edited there; had the gate passed, the missing staging config path would have made it report-only anyway.

Preview social auth: not applicable. The runnable frontend has no sign-in UI (single Home route). samples/auth-web/ contains GitHub-OAuth sample components but is unreferenced dead sample code with no package.json, and the backend installs allauth.account without allauth.socialaccount or any social provider.

Changes

• Add .codepress/dev-server/recipe.json — schema_version 1, one web frontend entry (cra/yarn, dev_port 3000, yarn.lock as the dependency manifest)
• Add .codepress/dev-server/Dockerfile.web — thin dev-mode image on full node:18-bookworm, procps, Yarn 1 pinned via corepack, HMR/bind wired to runtime env vars, react-scripts start bound to 0.0.0.0
• Omit staging_backend_url — no staging URL is declared anywhere in the repo, so none was guessed
• No backend CORS edit — the Django app has no CORS surface and is served same-origin; no staging settings path exists either

Test plan

• Sanity-check the contract: python3 -c "import json;print(json.load(open('.codepress/dev-server/recipe.json'))['frontends'])" — one entry, label web, working_dir web, dev_port 3000, and .codepress/dev-server/Dockerfile.web exists on disk.
• Build the dev image from the repo root: docker build -f .codepress/dev-server/Dockerfile.web -t drx-web . — it should complete in seconds, since the image bakes only the toolchain (no yarn install, no source copy).
• Run it the way the Live Dev Server does — deps on the bind-mounted checkout, then the dev command: docker run --rm -v "$PWD:/app" -w /app/web --entrypoint yarn drx-web install --frozen-lockfile followed by docker run --rm -p 3000:3000 -v "$PWD:/app" drx-web. Expect Compiled successfully! and react-scripts start listening on 0.0.0.0:3000.
• Confirm the bind and the host check: curl -sI http://localhost:3000/ returns 200, and curl -sI -H 'Host: abc123.preview.codepress.dev' http://localhost:3000/ also returns 200 rather than Invalid Host header (this is what DANGEROUSLY_DISABLE_HOST_CHECK buys).
• Confirm hot reload: with the container running, edit web/src/containers/home/Home.js on the host and verify the browser at http://localhost:3000 updates without a manual refresh (the HMR socket rides the page origin).
• Open a CodePress preview for this branch after merge and confirm the React welcome page renders at the preview URL and that edits hot-reload.

Open items

• The dev image was not built or booted in this session — no Docker daemon was available in the bootstrap environment. Instead of guessing, the risky assumptions were verified against the published react-scripts@1.0.10, webpack@2.6.1, and react-dev-utils@3.x tarballs (md5 hashing, DANGEROUSLY_DISABLE_HOST_CHECK support, window.location-based HMR socket) and the node:18-bookworm tag was confirmed present on the ECR-public mirror. The docker build/docker run steps in the test plan are the outstanding check.
• Node 18 is a judgement call, not a repo constraint — nothing here pins a Node version. If a yarn install --frozen-lockfile of this 2017 lockfile misbehaves, the single line to change is the FROM in Dockerfile.web (e.g. node:16-bullseye).
• If this repo later grows a cross-origin API caller (the React app fetching an absolute backend URL) plus a staging settings path, re-run /codepress-bootstrap-dev-server — it will then add the staging-scoped preview CORS allowance that is intentionally absent today.

Authors

Generated with CodePress · View the chat session

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