Bootstrap CodePress Live Dev Server recipe + dev Dockerfile

[codepress-dev]

Summary

This sets up the files CodePress needs to spin up a live, hot-reloading preview of this project's React app (web/). Until now a preview would have had to guess how to boot the app; now the repo itself declares it, so previews start the same way every time and keep working as the project changes. Nothing about how the app runs locally or in production changes — these are new files under .codepress/dev-server/ plus a preview-only Dockerfile that is never used by a real deployment. One thing worth knowing: this app is pinned to a 2017-era React toolchain (Create React App 1.0.10 / React 15), which cannot run on a current Node release without crashing on startup, so the preview image pins Node 16 to match it. Two other pieces of the bootstrap found nothing to do and made no changes: there is no staging backend URL declared anywhere in the repo to pre-fill, and the Django API here is served same-origin by design, so it needs no preview CORS allowance.

Technical details

.codepress/dev-server/recipe.json — the contract the Live Dev Server reads. schema_version: 1, one frontends[] entry:

• working_dir: "web", framework: "cra", package_manager: "yarn" (resolved from web/yarn.lock; no packageManager field is declared), dev_port: 3000 (CRA default — the start script passes no --port), install_command: "yarn install --frozen-lockfile", dependency_manifests: ["web/yarn.lock"], system_packages: ["procps"], size: "medium".
• dev_command is sh -c 'HOST=… PORT=… WDS_SOCKET_PORT=… BROWSER=none yarn start' — routed through yarn rather than invoking react-scripts bare, since the dev container's shell has no node_modules/.bin on PATH.
• prebuild_command / prebuild_inputs are empty: web/'s start script is a single command with no build prefix, no predev hook, and no workspace sibling to build.
• staging_backend_url is omitted, not empty — there is no .env*, vercel.json, CI workflow, or proxy rewrite in the repo declaring a backend URL, and the rule is never to persist a guess. The frontend-env prefill step is gated on a confident staging URL, so it was skipped too (no Live Dev Server env vars were written).

.codepress/dev-server/Dockerfile.web — thin, dev-mode, toolchain-only image. No COPY, no baked node_modules (the runtime bind-mounts the checkout at /app and provides deps); WORKDIR /app then /app/web; procps installed for clean dev-process shutdown; HOSTNAME/CODEPRESS_BIND_HOST/PORT/CODEPRESS_HMR_CLIENT_PORT/CODEPRESS_HMR_PROTOCOL declared with defaults so the runtime injects real values; CMD is the dev command, never a production build.

The decision worth reviewing is node:16-bookworm instead of the current LTS. react-scripts@1.0.10 resolves to webpack@2.6.1, which hashes with MD4. OpenSSL 3 (Node 17+) removed MD4 from the default provider, so on Node 18/20/22 the dev server dies at startup with error:0308010C:digital envelope routines::unsupported. Node 16 ships OpenSSL 1.1.1 and runs webpack 2 unmodified, which is cleaner than relying on a NODE_OPTIONS=--openssl-legacy-provider workaround. The base is pulled from public.ecr.aws/docker/library/node:16-bookworm (tag confirmed present on the mirror) to avoid Docker Hub rate limits, and it is the full -bookworm image, not -slim, so runtime native installs have the node-gyp toolchain. If react-scripts is ever upgraded, this base should be bumped — there is a comment saying so.

Two supporting details: yarn is baked with (command -v yarn || npm install -g yarn@1.22.22) so a cold start never fetches a package manager from the registry (the node base already ships yarn 1.x; the fallback covers a future base that doesn't). WDS_SOCKET_PORT is set for the uniform runtime contract but is inert on webpack-dev-server@2.5.0, which derives its HMR socket URL from window.location — that already resolves to the public preview origin behind the proxy, so HMR needs no extra wiring here. DANGEROUSLY_DISABLE_HOST_CHECK=true and BROWSER=none are set so the dev server accepts the proxied preview hostname and doesn't try to launch a browser in a container.

No backend CORS change, deliberately. The Django app in server/ was detected, but it fails the cross-origin gate on both counts: it carries no CORS allowlist at all (django-cors-headers is not a dependency and nothing sets CORS_*), and no caller in this repo reaches it cross-origin — web/src makes zero fetch/XHR calls, and in production web/package.json's postbuild copies the built bundle into server/static/build/ where Django's catch-all index view renders it, i.e. same-origin by construction. Independently, the repo has no staging config path to scope such an edit to (a single server/server/settings.py, no .env files, no CI), so an auto-edit would have been report-only regardless.

Changes

• Add .codepress/dev-server/recipe.json declaring the web/ frontend (CRA, yarn, port 3000)
• Add .codepress/dev-server/Dockerfile.web — thin dev-mode image pinned to node:16-bookworm for webpack 2 / OpenSSL 1.1.1 compatibility
• Omit staging_backend_url — no staging backend URL is declared anywhere in the repo
• No preview-CORS edit — the Django API is same-origin and carries no CORS surface

Test plan

• Confirm .codepress/dev-server/recipe.json parses and reports schema_version: 1 with a single web frontend: python3 -c "import json;print(json.load(open('.codepress/dev-server/recipe.json')))"
• Build the dev image from the repo root and confirm it succeeds on the pinned base: docker build -f .codepress/dev-server/Dockerfile.web -t drx-web-dev .
• Run it against the checkout and confirm CRA boots without the OpenSSL/MD4 error, then serves on 0.0.0.0:3000: docker run --rm -p 3000:3000 -v "$PWD:/app" -w /app/web drx-web-dev sh -c 'yarn install --frozen-lockfile && exec sh -c "HOST=0.0.0.0 PORT=3000 BROWSER=none yarn start"' — expect Compiled successfully! and a working page at http://localhost:3000
• Verify hot reload: with that container running, edit web/src/containers/home/Home.js (change the Welcome to React heading) and confirm the browser updates without a manual refresh
• Sanity-check the Node pin by swapping the base to node:22-bookworm and rebuilding — the dev server should fail with error:0308010C:digital envelope routines::unsupported, which is the reason Node 16 is pinned
• Open a CodePress preview for this branch and confirm the web frontend starts from the committed recipe (dev port 3000) rather than a runtime guess

Open items

• The dev image could not be built or booted in this bootstrap session (no Docker available), so the Node 16 / webpack 2 compatibility reasoning is verified by version analysis of web/yarn.lock (react-scripts@1.0.10 → webpack@2.6.1) rather than by a live run. The build/run steps in the test plan are the check for it.
• node:16-bookworm is an end-of-life Node line, chosen because the app's 2017 toolchain cannot start on a supported one. The durable fix is upgrading react-scripts, after which this base should move to the current LTS.
• If this project ever splits the React app and the Django API onto different origins (frontend served separately instead of from server/static/build/), previews will then need a staging-scoped CORS allowance for the preview origin — there is no staging settings module or .env.staging in the repo today to put one in.

Authors

Generated with CodePress · View the chat session

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