31 lines
2.1 KiB
Markdown
31 lines
2.1 KiB
Markdown
|
# Repository Guidelines
|
||
|
|
|
||
|
|
## Project Structure & Module Organization
|
||
|
|
- `app/app.vue` hosts the root Nuxt view; keep it lean and delegate features to components under a future `components/` directory.
|
||
|
|
- `public/` holds static assets served as-is.
|
||
|
|
- `nuxt.config.ts` centralizes Nuxt settings; add modules and runtime config here instead of inside components.
|
||
|
|
- `package.json` scripts are the source of truth for commands; avoid ad-hoc shell scripts.
|
||
|
|
|
||
|
|
## Build, Test, and Development Commands
|
||
|
|
- `npm run dev` — start Nuxt dev server at `http://localhost:3000` with HMR.
|
||
|
|
- `npm run build` — production build; ensure this passes before merging.
|
||
|
|
- `npm run preview` — serve the production build locally to validate routes and assets.
|
||
|
|
- `npm run generate` — create a static export for static hosting targets.
|
||
|
|
- Install dependencies with `npm install` (npm lockfile is committed).
|
||
|
|
|
||
|
|
## Coding Style & Naming Conventions
|
||
|
|
- Language: Vue 3 with Nuxt 4; prefer `<script setup lang="ts">` and the Composition API.
|
||
|
|
- Formatting: 2-space indentation; run a formatter (e.g., `npx prettier`) before pushing; keep templates tidy and avoid inline styles when practical.
|
||
|
|
- Naming: PascalCase for components (`HeroSection.vue`), camelCase for composables/utilities (`useFeatureFlag`), kebab-case for file names except Vue components.
|
||
|
|
- Imports: use Nuxt aliases for clarity (e.g., `~/components/Button.vue`) instead of long relative paths.
|
||
|
|
|
||
|
|
## Testing Guidelines
|
||
|
|
- No automated tests are configured yet; add coverage with new features rather than deferring.
|
||
|
|
- If you add tests, co-locate unit specs with components (`Button.spec.ts`) and keep integration/E2E flows under `tests/`.
|
||
|
|
- Always run `npm run build` and do a quick browser smoke test of impacted routes before opening a PR.
|
||
|
|
|
||
|
|
## Commit & Pull Request Guidelines
|
||
|
|
- Commits: imperative mood (`Add hero CTA copy`) and scoped to a single concern; avoid mixing refactors with feature work.
|
||
|
|
- Pull Requests: include a concise summary, screenshots or recordings for UI changes, reproduction steps for fixes, and any follow-up items.
|
||
|
|
- Link issues when relevant and call out breaking changes explicitly in the description.
|