Skip to main content

Website engineering guide

Use this guide when contributing to the Website repository. Repository access requires authorization. It describes checked-in development and validation paths; it does not provide customer configuration, credentials, or deployment authorization.

Architecture​

The Website is a React 18 single-page application built with Vite. React Router v5 owns browser navigation, context providers coordinate session, configuration, ordering, theme, and consent state, and styled-components supplies the runtime theme layer. Page modules live in the application source directory and load through its router and app shell.

Reusable commerce logic and UI arrive through the Components Git submodule mounted in the application source directory. Treat the app and its pinned submodule revision as one build input: a change that works against another Components revision is not validated for this repository.

The production build writes static assets to dist. The checked-in Cloudflare Worker serves those assets and owns request-time routing, runtime configuration injection, and SEO-related responses. The Vite development server does not prove Worker behavior.

Repository map​

PathResponsibility
Application entry, app shell, and routerBrowser entry point, providers, gates, lazy-loaded pages, and routes.
Application pages, components, and contextsCustomer-facing routes, Website-specific UI, and state boundaries.
Components submodulePinned shared commerce logic and UI.
Application configuration and theme filesPublic client configuration merge and theme defaults.
Application unit-test directoryVitest and Testing Library coverage owned by this repository.
e2e/docs/Deterministic documentation contracts and Playwright capture flows.
i18n/Generated catalog checks and translation utilities.
worker/ and wrangler.tomlCloudflare asset, routing, runtime configuration, and SEO boundary.

Prerequisites and safe setup​

  • Git 2.30 or newer.
  • Node.js 24 or newer, matching package.json and CI.
  • pnpm 9; the repository pins pnpm 9.15.0.
  • A supported browser for local development.

Obtain repository access from its owner and use the approved authentication method. From an authorized checkout, initialize submodules and install the locked dependency graph:

git submodule update --init --recursive
corepack enable
corepack prepare pnpm@9.15.0 --activate
pnpm install --frozen-lockfile

Do not delete a lockfile, advance the submodule to another branch, substitute an arbitrary Components checkout, or copy environment values into the repository as part of setup.

Configure a safe local project​

The application configuration contains browser-visible defaults and merges them with runtime configuration supplied by the Worker. Keep this boundary explicit:

  • Treat everything shipped to the browser as public.
  • Use only a development project that you are authorized to access.
  • Never place API secrets, private keys, privileged tokens, customer exports, or production-only provider credentials in client configuration.
  • Preserve the nested API configuration shape and validate changes with the configuration tests.
  • Configure Worker values through the approved environment mechanism. Do not copy environment values into source, examples, screenshots, or issue text.

Product mode, project resolution, canonical routes, and provider availability can change the visible experience. Use Website experience and configuration before assuming that one project represents every installation.

Run and validate locally​

Start the Vite development server:

pnpm start

Create a production bundle and serve it locally when the work requires it:

pnpm build
pnpm preview

Use pnpm cf:dev only when you need the checked-in Worker boundary locally. An HTTPS tunnel is an optional, externally reachable test surface; use it only with non-sensitive fixtures and an authorized review scope.

Run the smallest relevant checks while developing, then the same quality gates used by CI:

pnpm lint:check
pnpm test
pnpm i18n:check-generated
pnpm i18n:verify
pnpm build

For changes to documentation behavior, also run pnpm docs:website:contract. Use pnpm lint:check for a read-only lint result; pnpm lint may apply fixes.

Recognize legacy repository layouts​

Captured legacy material distinguishes Ordering-UI-release, which supplied components, from Ordering-Website-release, which contained frontend code and loaded components at compile time. In the current repository, use the pinned Components submodule and the package-manager/lockfile instructions above; do not apply the old Yarn, path-editing, or lockfile-removal steps to a current checkout.

Captured legacy Ordering UI repository opened in an editor Captured legacy project configuration path

Locate a component before changing it​

Identify the customer-facing element, trace its parent and child components, and review the component’s dependencies before editing. React Developer Tools can help identify a component tree in a local, authorized browser session, but it does not prove that a component can be copied or changed independently.

Captured address-entry element selected for component investigation Captured React Developer Tools component inspection Captured component hierarchy and source-directory example

Treat the source component, related styles, context, routes, tests, and shared submodule as one review scope. A legacy example that copies a HomeHero component into src/components is not a current permission to fork or replace the governed component.

Make a reviewable change​

Locate the page and import that render the intended surface, then make the smallest change that preserves the shared component boundary. Do not rewrite import aliases or component paths merely to make an older example compile; resolve the actual dependency relationship in the current pinned checkout.

Captured legacy page import configuration Captured legacy component import-path change Captured legacy dependency-path adjustments Captured local component style change

Build and release boundary​

pnpm build is the local production-bundle check. pnpm cf:build additionally refreshes the pinned submodule and installs the frozen lockfile before building for Cloudflare.

The captured builder sequence includes a custom-file area, file paths, search-and-replace validation, a build action, and a staging synchronization action. These are external-state operations. Do not upload files, run a build in the builder, synchronize staging, or deploy without an authorized release owner, an approved environment, and a defined rollback/review process.

Captured legacy builder custom-file configuration Captured legacy builder file-path configuration Captured legacy builder file-list configuration Captured legacy builder search-and-replace validation Captured legacy builder build and staging synchronization controls

A successful local build or preview confirms that build or preview only. Verify the deployed revision, environment, routes, and required configuration in your organization's release system.

Troubleshooting​

SymptomCheck
Imports under the shared aliases cannot resolveRun git submodule status, then initialize the pinned submodule. Do not replace it with an arbitrary Components checkout.
The app starts but shows the wrong experienceCheck only the non-secret project and mode fields in the effective local configuration. Confirm the project is intended for development.
A deep link redirects or opens another screenCompare it with Website routes and deep links; account, location, profile, cart, and product availability gates still apply.
Vite works but the Worker preview differsReproduce with pnpm build and pnpm cf:dev; the Worker adds routing, runtime configuration, and SEO behavior.
Tests run out of memoryUse the repository pnpm test script, which applies its maintained memory and worker limits.
Generated translations fail CIRun pnpm i18n:check-generated and pnpm i18n:verify; update source keys and generated catalogs together.

Security boundaries​

  • Browser visibility is not API authorization. Enforce identity, resource ownership, and mutations on the server contract.
  • Never log or publish session tokens, temporary order links, payment tokens, integration handoffs, customer addresses, or provider assertions.
  • Keep payment collection inside the supported provider component; do not add raw payment data to app state, URLs, analytics, or diagnostics.
  • Preserve consent gates for analytics, tracking, and project code.
  • Validate redirect and host-derived project behavior at the Worker boundary. Do not trust a client header, hostname, or query value as tenant authority.
  • Use the API Reference for published server contracts and Website integrations and external handoffs for provider ownership.

Related references: Website developer reference · Website routes and deep links · Website integrations and external handoffs