Dev 44 develop boilerplate new appointment booking app#1062
Conversation
…, strict TS, and path aliases
…n system - Create folder structure (components, services, models, utils, hooks) - Install @bcgov/design-system-react-components and @bcgov/design-tokens - Create Layout, Page, and Button wrapper components - Add BC Gov branding and styling (header, footer, theme colors) - Update license-check to include 0BSD (permissive) - All quality gates pass: type-check, lint, license-check, build
Introduce a multi-stage Dockerfile for the appointment-booking SSR application. The builder stage uses node:22-alpine to install dependencies (npm ci --legacy-peer-deps), copy source, and run the build. The runtime stage installs production dependencies, copies built artifacts (dist, server.js, public) from the builder, exposes port 5173, configures a healthcheck against /config/runtime-config.json, sets NODE_ENV=production, and runs server.js.
SummaryThis PR delivers the initial boilerplate for the new appointment-booking React app. It sets up a working foundation with SSR, API connectivity to the Q backend, automated checks, and Docker support so feature work can start on a stable base. What was implemented
Steps to TestPull up this branch:
docker start citz-sbc-queue-postgres-1If not present: docker compose up -d db
cd api
uv sync
DATABASE_HOST=127.0.0.1 DATABASE_PORT=5432 DATABASE_NAME=sbc_queue DATABASE_USERNAME=postgres DATABASE_PASSWORD=postgres uv run gunicorn wsgi --bind=0.0.0.0:5100 --access-logfile=- --config=gunicorn_config.py --reload --timeout=0
cd appointment-booking
npm install --legacy-peer-deps
npm run dev:local
curl -i http://localhost:5173/config/runtime-config.json
curl -i http://localhost:5173/api/v1/healthz/
curl -i http://localhost:5173/api/v1/offices/
npm run ci:check
docker build -t appointment-booking:test .Expected results
Notes
|
Removed unnecessary commands from the setup instructions.
chrsamp
left a comment
chrsamp
left a comment
There was a problem hiding this comment.
Hey @veenupunyani,
Overall, this is a great foundation. I only have a few small comments (with the exception of the proxy issue below). I’m especially glad to see SSR included up front, along with the Dockerfile and a quick smoke test for API connectivity.
We can chat offline, but I’d like to better understand the choice of a vanilla React + Vite app versus something like Next. To be clear, I don’t have concerns with the approach itself. I just want to make sure I understand the rationale, since once we need SSR, routing, caching, and similar concerns, not using a framework tends to be the less common path. I’d like to be well-versed in why we’re choosing it here.
I also had a question about the API request proxying around the macOS port 5000 issue. I see where you’re coming from, but I don’t think I fully understand the tradeoff yet. It’s causing some issues for me locally, and I’d be curious whether you’re seeing the same thing. If we do need to proxy requests, I think it may be worth using Vite’s built-in dev proxy rather than maintaining our own custom proxy.
One other thought: there are already tasks defined in .vscode/launch.json for starting services, and we could extend those to include a new task for the appointment-booking frontend. There’s also a compound task for starting all services, which works both locally and in a dev container. Since the root README.md already covers things like database bootstrapping, environment setup, and service startup, I think it may be cleaner for this README to point users there and stay focused on frontend-specific instructions.
Nice work getting this set up. This gives us a solid base to iterate from.
Remove legacy npm flags and tidy dev setup for the appointment-booking app. Updated CI workflow and Dockerfile to use plain `npm ci`, added a VS Code launch configuration for the SSR front end, and added a recorded CI output file. README was simplified and clarified (dev vs prod proxy vars and startup steps). package-lock.json was adjusted to reflect dependency/peer changes and an unused Button component was removed along with small frontend/config tweaks. also removed hardcoded css by importing the bc desing system css file
Add an explicit step to the appointment-booking GitHub Actions workflow to install npm@11 globally prior to running npm ci to ensure a consistent npm version in the CI environment. The package-lock.json was updated by npm as part of this change.
|
|
hi @chrsamp thanks for the thorough review, I have now fixed these issues/concerns, please re-review the PR. |
chrsamp
left a comment
chrsamp
left a comment
There was a problem hiding this comment.
LGTM! 🚀 Thanks for the quick turnaround @veenupunyani
2 participants
This pull request sets up the initial boilerplate for a React + TypeScript project using Vite, including configuration for linting, formatting, and TypeScript. It establishes basic project structure, tooling, and a minimal application entry point, making the repository ready for further development.
Project setup and configuration:
package.jsonwith scripts for development, build, linting, formatting, type-checking, and license checking, and included all necessary dependencies and devDependencies for React, TypeScript, Vite, ESLint, and Prettier.tsconfig.json,tsconfig.app.json, andtsconfig.node.jsonfor strict type-checking, modern module resolution, and path aliases. [1] [2] [3]vite.config.tswith React plugin and path alias for@to thesrcdirectory.Linting and formatting:
eslint.config.jswith recommended rules for JavaScript, TypeScript, React hooks, React Refresh, and Prettier integration..prettierrcto enforce code style..gitignoreto exclude logs, build output,node_modules, and editor files.Base application structure:
index.htmlas the entry point,src/main.tsxto bootstrap the React app, and a minimalApp.tsxcomponent with placeholder content. [1] [2] [3]src/index.cssfor future styling.Documentation:
README.mdwith setup instructions, information about the stack, and guidance on extending ESLint configuration for production use.