20 lines
2.7 KiB
Markdown
20 lines
2.7 KiB
Markdown
# 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.
|