|
| 1 | +# Repository Guidelines |
| 2 | + |
| 3 | +## Project Structure & Module Organization |
| 4 | + |
| 5 | +- React client code lives in `src/`, with shared UI in `src/components`, feature bundles in `src/features`, and hooks/services under `src/hooks`, `src/services`, and `src/utils`. |
| 6 | +- The Node.js API, GraphQL schema, and auth logic are in `server/src`; configs and migrations sit under `server/src/configs` and `server/src/db`. |
| 7 | +- Workspace packages in `packages/` expose shared config (`@rm/config`), localization, logging, masterfile data, and build plugins; treat them as the source of truth for cross-app utilities. |
| 8 | +- Static assets are sourced from `public/`, while built bundles land in `dist/`; avoid committing build artefacts or anything listed in `.gitignore`. |
| 9 | + |
| 10 | +## Build, Test, and Development Commands |
| 11 | + |
| 12 | +- `yarn install` – install workspace dependencies; rerun after pulling lockfile changes. |
| 13 | +- `yarn dev` – start the full dev stack (Nodemon backend + Vite) using local config. |
| 14 | +- `yarn watch` – Vite-only hot reload for rapid UI work when the API is proxied elsewhere. |
| 15 | +- `yarn build` – create a production bundle in `dist/`; ensure it succeeds before release PRs. |
| 16 | +- `yarn lint` / `yarn lint:fix` – run ESLint with the Airbnb ruleset; lint must pass pre-commit. |
| 17 | +- `yarn prettier` / `yarn prettier:fix` – enforce formatting for JS/JSX, CSS, HTML, and YAML. |
| 18 | +- `yarn config:env` and `yarn locales:generate` – regenerate env files and derived locales after editing base config or strings. |
| 19 | + |
| 20 | +## Coding Style & Naming Conventions |
| 21 | + |
| 22 | +- Prettier governs formatting (2-space indent, single quotes in JS, semicolons off); never hand-format conflicting styles. |
| 23 | +- Prefer functional React components, PascalCase for components, camelCase for helpers, and `use` prefixes for hooks. |
| 24 | + |
| 25 | +## Testing Guidelines |
| 26 | + |
| 27 | +- No dedicated Jest suite today; rely on `yarn lint`, type checks from editor tooling, and manual verification in a local dev session. |
| 28 | +- When adding backend features, exercise relevant GraphQL/REST paths via the dev server and document sanity checks in the PR description. |
| 29 | + |
| 30 | +## Commit & Pull Request Guidelines |
| 31 | + |
| 32 | +- Use Conventional Commits (`type(scope): summary`), matching existing history (e.g. `feat(map): add weather overlays`). |
| 33 | +- Each PR should describe scope, link related issues, list testing steps, and include screenshots or GIFs for UI changes. |
| 34 | +- Re-run `yarn lint`, `yarn build`, and integration steps touched by the change before requesting review. |
| 35 | + |
| 36 | +## Localization Notes |
| 37 | + |
| 38 | +- Update English copy only in `packages/locales/lib/human/en.json`; run `yarn locales:generate` to refresh derived languages. |
| 39 | +- When adding a new translation key (for example when calling `t('some_key')`), create the English entry in `packages/locales/lib/human/en.json` in the same change. NEVER use fallback strings. |
| 40 | +- Never edit generated locale files directly—the automation pipeline syncs translations downstream. |
0 commit comments