Bootstrap CodePress Live Dev Server recipe + dev Dockerfile

[codepress-dev]

Summary

This sets up the Live Dev Server for django-react-intro so CodePress previews of this repo boot from files committed here rather than guessing at runtime. It adds a small .codepress/dev-server/ folder describing the one runnable frontend in this repo — the create-react-app in web/ — plus the container recipe used to run it with hot reloading. Nothing about how the app builds or behaves changes; these files are only read when a CodePress preview starts up. Two things were deliberately left alone: no staging backend URL was recorded (the repo doesn't declare one anywhere, and guessing one risks pointing previews at the wrong environment), and no CORS change was made to the Django backend, because this project serves the React bundle from Django on the same origin and has no cross-origin API surface to open up.

Technical details

recipe.json — schema_version: 1 with a single frontends[] entry: working_dir: "web", framework: "cra", package_manager: "yarn" (from web/yarn.lock; no packageManager field anywhere), dev_command: "yarn start", install_command: "yarn install --frozen-lockfile", dependency_manifests: ["web/yarn.lock"], dev_port: 3000, system_packages: ["procps"], size: "medium". prebuild_command is empty — web/package.json's only build hook is postbuild (copies the production build into server/static/build/), which is a production concern, not a dev prebuild.

Dockerfile.web — thin, toolchain-only: no COPY, no baked node_modules, no CodePress binary. WORKDIR /app → /app/web, procps via apt, PATH backstop for node_modules/.bin, and the runtime env contract (PORT, CODEPRESS_BIND_HOST, CODEPRESS_HMR_CLIENT_PORT, CODEPRESS_HMR_PROTOCOL).

Two decisions worth a close look:

• Base is node:16-bookworm, not the current LTS. web/package.json pins react-scripts 1.0.10, which resolves (per web/yarn.lock) to webpack 2.6.1. webpack 2/3 hash modules with md4, and OpenSSL 3 — bundled from Node 17 on — removed md4, so a modern base fails immediately with error:0308010C:digital envelope routines::unsupported. Node 16 ships OpenSSL 1.1.1, so the dev server runs without patching the app. The full -bookworm variant (never -slim) keeps the node-gyp toolchain available for the runtime install. I confirmed node:16-bookworm exists on ECR Public with a linux/amd64 manifest.
• Corepack is intentionally NOT enabled. The repo declares no packageManager field, and yarn 1.x already ships in the node:16 base. Enabling corepack would shadow that working yarn with a shim that tries to fetch a package manager from the public registry on every cold start. A RUN yarn --version assertion makes a future base-image swap fail loudly at build time instead of at dev-command time.

HMR: the pinned react-dev-utils 3.0.2 builds its SockJS URL from window.location, so HMR already follows the public preview origin (like Next.js) and needs no client-port flag. WDS_SOCKET_PORT is still mapped from CODEPRESS_HMR_CLIENT_PORT in the CMD for forward compatibility, since only react-scripts ≥ 3.4 honors it. DANGEROUSLY_DISABLE_HOST_CHECK=true is set so webpack-dev-server accepts the proxied preview Host header — this is a dev-only image that never produces a production build.

Why no preview-CORS edit: server/ is Django, but there are zero CORS references anywhere in the repo (no django-cors-headers in Pipfile/Pipfile.lock, no corsheaders in INSTALLED_APPS, no CORS_* settings), and web/src makes no API calls at all — no fetch/axios, no absolute API base URL, no CRA proxy field. Django's catch-all route renders the CRA build from static/build same-origin. So neither cross-origin-caller signal holds and there is nothing to allow. Separately, the repo has no staging config path at all (one flat settings.py, no settings/ package, no .env*, no CI workflows), so a preview-origin allowance would have had nowhere staging-scoped to live even if it were warranted.

Why no social-auth work: the only social sign-in code is samples/auth-web/ (a GithubButton), which is dead reference material — not imported by web/src, and outside CRA's src/ compile root, so it cannot build. The backend installs allauth/rest_auth but enables no allauth.socialaccount provider and wires no provider routes, so no sign-in flow is reachable from a preview.

Changes

• Add .codepress/dev-server/recipe.json — schema_version 1, one frontend entry for the web/ create-react-app (yarn, port 3000)
• Add .codepress/dev-server/Dockerfile.web — thin dev-mode image on node:16-bookworm that binds 0.0.0.0, installs procps, and wires HMR/bind to the runtime env vars
• Omit staging_backend_url — no staging backend URL is declared anywhere in the repo, so nothing was persisted rather than guessing
• No backend CORS change — the Django app serves the React bundle same-origin and has no CORS surface or cross-origin caller

Test plan

• Confirm the recipe is well-formed and matches the repo: python3 -c "import json;r=json.load(open('.codepress/dev-server/recipe.json'));print(r['schema_version'], r['frontends'][0]['working_dir'], r['frontends'][0]['dev_port'])" → prints 1 web 3000, and .codepress/dev-server/Dockerfile.web exists at the recorded dockerfile_path.
• Build the dev image from the repo root (the build context is the repo root, so pass -f): docker build -f .codepress/dev-server/Dockerfile.web -t drintro-web-dev . → build succeeds and the RUN yarn --version step prints a 1.x version.
• Boot it with deps mounted the way the runtime does, and confirm it binds all interfaces rather than localhost: docker run --rm -p 3000:3000 -v "$PWD:/app" drintro-web-dev → after yarn install --frozen-lockfile has populated web/node_modules, react-scripts prints Compiled successfully! and curl -s -o /dev/null -w '%{http_code}' http://localhost:3000/ returns 200.
• Verify hot reload: with the container running, edit the heading text in web/src/containers/home/Home.js and confirm the browser updates without a manual refresh (the HMR socket follows the page origin, so this also holds behind the preview proxy).
• Confirm the md4/OpenSSL reasoning by negative test: temporarily change the FROM line to node:22-bookworm, rebuild, and run → startup fails with error:0308010C:digital envelope routines::unsupported. Revert the line afterwards.
• Confirm the image stayed thin: docker history drintro-web-dev shows no yarn install layer and no source COPY, and docker run --rm drintro-web-dev sh -c 'ls /app' is empty without a bind mount.

Open items

• The dev image could not be built or booted in this bootstrap environment (no Docker available), so validation was static: the recipe and Dockerfile were checked against the contract programmatically, the CMD was extracted and verified to parse under sh -n and to expand HOST/WDS_SOCKET_PORT correctly both with runtime-injected values and with image defaults, and node:16-bookworm was confirmed present on ECR Public for linux/amd64. The first real docker build + boot (test plan steps 2–3) is the outstanding verification.
• react-scripts 1.0.10 / React 15 is from 2017 and is the reason the base image is pinned to Node 16. If the frontend is ever upgraded, revisit the pin and the corepack decision — a modern react-scripts would allow the current LTS base and could then honor WDS_SOCKET_PORT directly.
• If a cross-origin API is added later (a real staging deployment, or the frontend calling Django on a different origin), preview CORS will need to be set up at that point — it was correctly a no-op here. That work also needs a staging-only config path, which this repo does not yet have (one flat settings.py, no .env*).

Authors

Generated with CodePress · View the chat session

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