Bootstrap CodePress Live Dev Server recipe + dev Dockerfile

[codepress-dev]

Summary

This sets up the files CodePress needs to run a live, hot-reloading preview of this project's React app. Until now the preview would have had to guess how to start the app; now the repo itself declares it, so previews boot the same way every time and the setup is reviewable and editable in git. The only runnable frontend here is the Create React App in web/, so there is one recipe entry and one preview image for it. Two things intentionally were not set up, because doing so safely wasn't possible from what's in the repo: no staging backend URL could be confidently detected (there are no environment files, CI workflows, or proxy rewrites naming one), and the Django API in server/ was left untouched — it has no cross-origin (CORS) setup at all today and serves the built React bundle itself, and the repo has no staging-only config to scope such a change to. Both are explained under Open items.

Technical details

.codepress/dev-server/recipe.json — schema_version: 1, one frontends[] entry: label: web, working_dir: web, framework: cra, package_manager: yarn, install_command: yarn install --frozen-lockfile, dependency_manifests: ["web/yarn.lock"], dev_port: 3000, system_packages: ["procps"], size: small. staging_backend_url is omitted rather than guessed. No prebuild_command — web/package.json has no predev/&&-chained dev script and no workspace package to build first.

.codepress/dev-server/Dockerfile.web — thin, toolchain-only dev image: full node:18-bookworm (from the public-ECR mirror), procps, corepack enable, WORKDIR /app → /app/web, no node_modules baked, no source COPY, no CodePress binary. Bind and HMR come from CODEPRESS_BIND_HOST / PORT / CODEPRESS_HMR_CLIENT_PORT / CODEPRESS_HMR_PROTOCOL; nothing hardcodes localhost. CMD is yarn start (react-scripts start), i.e. dev mode with HMR — never a production build.

Two decisions worth a look, both forced by the age of the toolchain (react-scripts@1.0.10 / webpack@2.6.1, verified from web/yarn.lock):

• Node 18, not the current LTS. webpack 2 hashes content with md4, which OpenSSL 3 removes from the default provider, so NODE_OPTIONS=--openssl-legacy-provider is set and the base image is pinned to the oldest Node LTS available as a bookworm image. Newer Node would crash the dev server on startup.
• HMR needs no client-port flag here. react-dev-utils@3.0.2's webpackHotDevClient builds its sockjs URL from window.location (protocol/hostname/port) with path /sockjs-node, so the browser already targets the public preview origin. WDS_SOCKET_PORT is still exported from CODEPRESS_HMR_CLIENT_PORT for contract uniformity (this version ignores it; newer react-scripts reads it). DANGEROUSLY_DISABLE_HOST_CHECK=true and BROWSER=none are set: webpack-dev-server 2.x's host check is already inert in this app (disableHostCheck: !proxy and web/package.json declares no proxy), so this is defensive against a proxy field being added later, which would otherwise make previews fail with "Invalid Host header".

samples/auth-web/ (which contains a GitHub OAuth button) was evaluated for the preview social-auth pass and excluded: it has no package.json and its imports (../../redux/auth, ../../../config/settings) don't resolve anywhere in this repo — it's reference code, not part of the runnable web/ app, whose router renders only Home. No auth files were changed.

Changes

• Add .codepress/dev-server/recipe.json declaring the web/ CRA frontend (yarn, port 3000)
• Add .codepress/dev-server/Dockerfile.web: thin dev-mode image, 0.0.0.0 bind, env-driven HMR
• Pin Node 18 + NODE_OPTIONS=--openssl-legacy-provider for webpack 2's md4 hashing
• Set BROWSER=none and DANGEROUSLY_DISABLE_HOST_CHECK=true so react-scripts start works headless behind the preview proxy

Test plan

• Build the dev image from the repo root: docker build -f .codepress/dev-server/Dockerfile.web -t drx-web-dev . — it should succeed without installing dependencies (thin image).
• Run it against the checkout: docker run --rm -p 3000:3000 -v "$PWD:/app" -w /app/web drx-web-dev sh -c 'yarn install --frozen-lockfile && export HOST=0.0.0.0 PORT=3000 BROWSER=none NODE_OPTIONS=--openssl-legacy-provider && yarn start' — the dev server should compile and log that it is listening on 0.0.0.0:3000 (no OpenSSL digital envelope routines::unsupported error).
• Open http://localhost:3000 and confirm the React home page renders.
• Edit web/src/containers/home/Home.js (change a visible string) and confirm the browser updates without a manual reload — HMR is live.
• Start a CodePress Live Dev Server preview for this repo and confirm it picks the web frontend from the recipe and the page loads at the preview URL.

Open items

• No staging backend URL was persisted. The repo has no .env* files, no .github/workflows, no vercel.json, and no proxy rewrites, so there was no candidate to classify — a production or guessed URL is never written. Previews still run; the backend URL field just isn't pre-filled. Nothing was pre-filled in the Live Dev Server env settings either, for the same reason.
• The Django API in server/ was deliberately not modified for preview CORS. It installs no CORS package (Pipfile: django, DRF, rest-auth, allauth), defines no allowlist, and is architecturally same-origin — web/'s postbuild copies the React build into server/static/build and the catch-all view renders it — and web/src makes no cross-origin API calls. There is also no staging-only settings module or .env.staging to scope such an allowance to, so an edit would have had to land in production config, which is not allowed. If a previewed frontend later calls this API cross-origin, add django-cors-headers with an anchored regex for the preview origin in a staging-only settings path; a CORS change only affects the live API after the backend is deployed.
• Preview social auth: not applicable. The runnable web/ app has no social or enterprise sign-in. samples/auth-web/ contains a GitHub OAuth sample but is unwired reference code (no package.json, imports that don't resolve). No provider-console registration is needed.

Authors

Generated with CodePress · View the chat session

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