2.7 KiB
Repository Guidelines
Project Structure & Module Organization
This migration pairs an Astro frontend with a Payload CMS backend. Keep UI work in frontend/src/components, route files in frontend/src/pages, and shared helpers in frontend/src/services or frontend/src/lib. Backend collections, auth flows, and integrations belong in backend/src, with companion contract tests under backend/tests. Product specs, research, and data contracts stay versioned in specs/001-users-pukpuk-dev/; mirror that layout when adding new feature folders so planning artifacts remain traceable.
Build, Test, and Development Commands
Run pnpm install once per clone to sync dependencies. Use pnpm dev for the Astro dev server at http://localhost:4321 while Payload runs via the same workspace. Before pushing, execute pnpm test:unit (Vitest) and pnpm test:e2e (Playwright) to guard regressions; record failures with the scenario name. If a production bundle is required, run pnpm build and confirm the output passes Payload schema checks.
Coding Style & Naming Conventions
Author frontend code in TypeScript/TSX with strict typing enabled. Prefer PascalCase for Astro components, camelCase for variables and functions, and kebab-case for file names below pages/. Align UI tokens with the palette in style-css.md and keep CSS modules scoped. On the backend, name Payload collections with singular PascalCase and expose slugs in kebab-case. Lint with the workspace Prettier config once it lands, and guard formatted diffs in pull requests.
Testing Guidelines
Write Vitest suites beside the module under test (*.spec.ts) and focus on rendering logic or domain helpers. Playwright feature specs live in frontend/tests/e2e/ and should mirror user flows from specs/001-users-pukpuk-dev/spec.md. Target meaningful coverage for auth, collection validation, and key marketing funnels. When introducing new endpoints, pair them with contract tests derived from contracts/*.yaml.
Commit & Pull Request Guidelines
Follow Conventional Commits as shown in git log (e.g., feat: generate tasks.md for website migration). Each PR should describe scope, link the corresponding spec or issue, and summarize manual or automated test results. Include screenshots or terminal captures for UX or CLI changes, note schema updates, and flag env variable additions.
Security & Configuration Tips
Store secrets in .env with PAYLOAD_CMS_URL and PAYLOAD_CMS_API_KEY; never commit the file. Rotate keys whenever staging or production data is refreshed and document rotations in the PR description. Validate that new integrations degrade gracefully when credentials are missing, and prefer typed accessors over reading directly from process.env within components.