|
| 1 | +## Purpose |
| 2 | + |
| 3 | +This file contains targeted, repository-specific guidance for AI coding agents working on the `bible-time` Nuxt 4 application. Use it to discover the architecture, developer workflows, conventions, and integration points that matter for code changes. |
| 4 | + |
| 5 | +## Quick overview |
| 6 | + |
| 7 | +- Tech: Nuxt 4 (Vue 3), TypeScript, Pinia, Nuxt UI (component library), Supabase (server & client), @nuxtjs/i18n, Zod. |
| 8 | +- Frontend lives in `app/` (pages, components, composables, stores). Server endpoints live in `server/api/`. |
| 9 | +- Shared TypeScript types live under `shared/` and generated Supabase types are placed at `shared/types/database-generated.types.ts` (see `package.json` script `supabase:types`). |
| 10 | + |
| 11 | +## Important files to open first |
| 12 | + |
| 13 | +- `nuxt.config.ts` — modules, aliases (`#server` -> `./server`), i18n config, sitemap sources, supabase types link. |
| 14 | +- `package.json` — dev scripts: `pnpm dev`, `pnpm build`, `pnpm preview`, `pnpm lint`, `pnpm typecheck`, and `pnpm supabase:types`. |
| 15 | +- `app/utils/supabase.ts` and `server/utils/supabase.ts` — central supabase helpers (error handling). Mirror patterns when adding new server/api code. |
| 16 | +- `shared/types/` — shared type contracts (database types and general types). |
| 17 | +- `server/api/` — server endpoints. Example files: `customers.ts`, `members.ts`, `mails.ts`, `notifications.ts`, `__sitemap__/urls.ts`. |
| 18 | + |
| 19 | +## Architecture notes & common patterns |
| 20 | + |
| 21 | +- Data flow: client pages (in `app/pages/`) and composables call server endpoints (`server/api/*`) which use Supabase utilities in `server/utils/supabase.ts`. Shared types in `shared/` are the contract between client and server. |
| 22 | +- Supabase types are generated with the `supabase` CLI and kept under `shared/types/`. Keep `nuxt.config.ts` setting `supabase.types` in sync if moving files. |
| 23 | +- Server routes follow Nuxt server API conventions. Add `server/api/yourname.get.ts` or `.post.ts` and use `defineEventHandler` / `createError` patterns (see `supabaseService.handleError`). |
| 24 | +- UI: components use Nuxt UI and composables live under `app/composables/`. Pinia stores are in `app/stores/`. |
| 25 | + |
| 26 | +### UI library (Nuxt UI) |
| 27 | + |
| 28 | +- This project uses Nuxt UI as its primary component library (installed as `@nuxt/ui` in `nuxt.config.ts`). Nuxt UI components are auto-registered and commonly use a `U` prefix (for example `UButton`, `UDropdownMenu`). |
| 29 | +- Local, app-specific components live under `app/components/` (see `app/components/home/*` and `app/components/people/*`). Prefer reusing Nuxt UI primitives and compose them into local components when you need project-specific behavior. |
| 30 | +- Use `.client` / `.server` component suffixes when you need to split rendering between server and client (this repo already contains examples: `app/components/home/HomeChart.client.vue` and `HomeChart.server.vue`). |
| 31 | +- When typing or interacting with Nuxt UI components in TypeScript, prefer using lightweight Vue `Component` types or the library's own types if available; avoid `any`. |
| 32 | + |
| 33 | +## Developer workflows & commands |
| 34 | + |
| 35 | +- Install: `pnpm install` (pnpm v10+ required per `package.json`). |
| 36 | +- Dev server: `pnpm dev` (runs `nuxt dev` and serves on http://localhost:3000). |
| 37 | +- Build: `pnpm build` then `pnpm preview` to locally preview the production build. |
| 38 | +- Linting: `pnpm lint` and auto-fix with `pnpm lint:fix`. |
| 39 | +- Typecheck: `pnpm typecheck` (uses `nuxt typecheck` / `vue-tsc`). |
| 40 | +- Generate Supabase types: `pnpm supabase:types` (invokes `supabase gen types` and writes to `shared/types/database-generated.types.ts`). |
| 41 | + |
| 42 | +## Conventions to follow (observed in repo) |
| 43 | + |
| 44 | +- TypeScript everywhere; avoid `any` where possible. When a temporary `any` is needed, prefer creating a narrow typed interface and add a TODO to refine. |
| 45 | +- Linter conventions: unused variables should be prefixed with `_` to satisfy the project's ESLint rules (e.g. `_unusedVar`). Avoid leaving declared-but-unused symbols. |
| 46 | +- Components use `<script setup lang="ts">` and Vue composition API patterns (see `eslint.config.mjs` rules). |
| 47 | +- Centralize Supabase error handling via `supabaseService.handleError` to ensure consistent HTTP errors. |
| 48 | + |
| 49 | +## Integration points & external dependencies |
| 50 | + |
| 51 | +- Supabase: configured via `@nuxtjs/supabase` (see `nuxt.config.ts`) — runtime auth redirect options and types configured there. |
| 52 | +- Sitemap: generated from server APIs: `/api/__sitemap__/urls?type=events` and `?type=people`. |
| 53 | +- i18n: uses `@nuxtjs/i18n` with `langDir: 'locales'` and `restructureDir: 'app'`. Adding pages/components must consider route prefixing for locales. |
| 54 | + |
| 55 | +## Troubleshooting & debugging tips |
| 56 | + |
| 57 | +- If runtime types are inconsistent, re-run `pnpm supabase:types` and `pnpm prepare` / `pnpm install` to refresh generated types and `.nuxt` artifacts. |
| 58 | +- To debug server endpoints, inspect `server/api/*` and `server/utils/supabase.ts`. Server logs appear in the terminal running `pnpm dev`. |
| 59 | +- For UI issues, check `app/components/`, `app/composables/`, and `app/stores/` in that order — composables often encapsulate data logic used across pages. |
| 60 | + |
| 61 | +## Where to add new functionality |
| 62 | + |
| 63 | +- New pages: `app/pages/your-page.vue` or nested route folders. Use `pages/<name>/index.vue` or dynamic `[slug].vue` as shown in `app/pages/people/[slug].vue`. |
| 64 | +- New API routes: create `server/api/<name>.get.ts` or `.post.ts`. Reuse `supabaseService.handleError`. |
| 65 | +- New shared types: add to `shared/types/` and, if needed, update generated supabase types. |
| 66 | + |
| 67 | +## Quick examples |
| 68 | + |
| 69 | +- Add a GET API route: `server/api/hello.get.ts` -> export default defineEventHandler(async () => { return { hello: 'world' } }) |
| 70 | +- Use supabase error handler in server code: |
| 71 | + - import { supabaseService } from '#server/utils/supabase' |
| 72 | + - on PostgrestError: `supabaseService.handleError(error, 500, 'Supabase error')` |
| 73 | + |
| 74 | +--- |
| 75 | + |
| 76 | +If anything above is unclear or you want more details about a particular area (build, auth flow, data model, or test setup), tell me which area to expand and I will update this file accordingly. |
0 commit comments