Nuxt 3 daje ci routing oparty na plikach, auto-importy, trasy serwera i renderowanie hybrydowe od razu po instalacji. Te przepisy pomagają ci używać narzędzi AI do budowania na tym fundamencie bez walki z konwencjami frameworka. Każdy prompt tutaj generuje kod, który respektuje strukturę katalogów Nuxt, wykorzystuje auto-importy i poprawnie obsługuje granice SSR/CSR.
Przepisy na trasy serwera obsługujące uwierzytelnianie, walidację i dostęp do bazy danych
Wzorce composables do pobierania danych z useFetch i useAsyncData
Przepisy na middleware i pluginy do strażników auth i globalnego stanu
Prompty wdrożeniowe dla Vercel, Cloudflare i Netlify edge
Scenariusz: Potrzebujesz endpointu POST do tworzenia postów na blogu z walidacją Zod, sprawdzaniem uwierzytelniania i poprawnymi odpowiedziami błędów.
Utwórz trasę serwera Nuxt w server/api/posts.post.ts. Użyj defineEventHandler z readValidatedBody i schematem Zod do walidacji. Schemat powinien wymagać title (string, 3-200 znaków), content (string, min 10 znaków), categoryId (UUID string), tags (tablica stringów, max 5) i publishedAt (opcjonalny ISO date string). Sprawdź nagłówek Authorization szukając tokena Bearer, zweryfikuj go używając verifyJWT() z server/utils/auth.ts. Jeśli nieprawidłowy, rzuć createError({ statusCode: 401, message: 'Unauthorized' }). Przy prawidłowym żądaniu wstaw do bazy danych używając Drizzle ORM, zwróć utworzony post ze statusem 201. Obsłuż duplikat tytułu odpowiedzią 409 Conflict. Napisz towarzyszący test używając $fetch z @nuxt/test-utils, który obejmuje prawidłowe tworzenie, błędy walidacji, błąd uwierzytelniania i duplikat tytułu.
Oczekiwane wyjście: Plik trasy serwera, schemat Zod i plik testowy z 4 przypadkami testowymi.
Scenariusz: Twoje strony wywołują useFetch bezpośrednio z powieloną obsługą błędów. Potrzebujesz composable, który to ustandaryzuje.
Utwórz composables/useApiData.ts, który opakowuje useFetch Nuxta z konsekwentnymi wzorcami. Composable powinien: (1) Przyjmować URL string i obiekt opcji. (2) Automatycznie dodawać token auth z useState('auth-token') do nagłówka Authorization. (3) Transformować odpowiedzi błędów w typowany obiekt ApiError z statusCode, message i opcjonalnymi błędami na poziomie pól. (4) Zapewniać refresh(), który ponownie pobiera, clear(), który resetuje dane, i retry(), który ponawia po błędzie. (5) Poprawnie obsługiwać SSR: podczas renderowania po stronie serwera używać ciasteczek z request event zamiast useState do auth. (6) Typować zwracane wartości jako { data: Ref<T | null>, error: Ref<ApiError | null>, pending: Ref<boolean>, refresh, clear, retry }. Utwórz typowane wrappery: useApiGet<T>(url), useApiPost<T>(url, body), useApiPut<T>(url, body), useApiDelete(url). Przetestuj, że composable obsługuje deduplikację payloadu SSR i reaktywność po stronie klienta.
Oczekiwane wyjście: Plik composable z typowanymi wrapperami, typ ApiError i testy.
Scenariusz: Chronione strony muszą sprawdzać uwierzytelnianie i przezroczyście odświeżać wygasłe tokeny bez przekierowania użytkownika.
Utwórz trzy elementy: (1) middleware/auth.ts — nazwany middleware trasy, który sprawdza prawidłowy token auth w useState('auth'). Jeśli brakuje, przekieruj do /login z parametrem query redirect zachowującym oryginalny URL. Jeśli token wygasł (sprawdź claim exp), wywołaj endpoint odświeżania przed zezwoleniem na nawigację. Jeśli odświeżanie się nie powiedzie, wyczyść stan auth i przekieruj do logowania. (2) middleware/guest.ts — dla stron logowania/rejestracji, przekieruj do /dashboard jeśli już uwierzytelniony. (3) plugins/auth.ts — plugin Nuxt uruchamiany przy inicjalizacji aplikacji, sprawdza istniejący refresh token w ciasteczkach i cicho przywraca sesję. Po stronie serwera czyta ciasteczko z eventu; po stronie klienta czyta z document.cookie. (4) Composable useAuth() udostępniający login(email, password), register(data), logout(), refreshToken() i obliczeniowy ref user. Chroń strony dodając definePageMeta({ middleware: 'auth' }). Przetestuj cały przepływ: logowanie ustawia tokeny, middleware blokuje nieuwierzytelniony dostęp, odświeżanie tokenu odbywa się przezroczyście, wylogowanie czyści wszystko.
Oczekiwane wyjście: Dwa pliki middleware, jeden plugin, jeden composable i testy integracyjne.
Scenariusz: Każda strona potrzebuje spójnych meta tagów, danych strukturalnych i automatycznie generowanej mapy strony.
Utwórz lokalny moduł Nuxt w modules/seo/index.ts używając defineNuxtModule. Moduł powinien: (1) Automatycznie wstrzykiwać domyślne useHead dla każdej strony: charset, viewport, domyślny szablon tytułu i typowe meta tagi (og:site_name, twitter:card). (2) Zapewniać composable useSeo(options), który ustawia title, description, og:image, canonical URL i dane strukturalne JSON-LD dla bieżącej strony. (3) Rejestrować plugin Nitro generujący /sitemap.xml przez skanowanie wszystkich stron w katalogu pages i odpytywanie bazy danych o dynamiczne trasy. (4) Dodać trasę serwera robots.txt, która odwołuje się do URL mapy strony. (5) Konfiguracja przez nuxt.config z seo: { siteUrl, defaultImage, twitterHandle }. Przetestuj, że meta tagi renderują się poprawnie w wyjściu SSR.
Oczekiwane wyjście: Katalog modułu z index.ts, composable, pluginy Nitro dla sitemap i robots, oraz testy.
Scenariusz: Twoje strony marketingowe powinny być statyczne, dashboard SSR, a blog ISR z 1-godzinną rewalidacją.
Skonfiguruj renderowanie hybrydowe w nuxt.config.ts używając routeRules. Ustaw: (1) '/', '/about' i '/pricing' na { prerender: true } dla statycznej generacji w czasie budowania. (2) '/blog/**' na { isr: 3600 } dla inkrementalnej statycznej regeneracji co godzinę. (3) '/dashboard/**' na { ssr: true } dla renderowania po stronie serwera przy każdym żądaniu. (4) '/api/**' na { cors: true, headers: { 'cache-control': 'no-store' } } dla tras API. (5) '/assets/**' na { headers: { 'cache-control': 'public, max-age=31536000, immutable' } } dla zasobów statycznych. Utwórz composables/useRenderMode.ts, który wykrywa bieżący tryb renderowania do debugowania. Dodaj stronę /debug/render-info (tylko development) pokazującą strategię renderowania bieżącej trasy.
Oczekiwane wyjście: Zaktualizowany nuxt.config.ts, composable trybu renderowania i strona debugowania.
Scenariusz: Twój dashboard potrzebuje aktualizacji na żywo dla zmian statusu zamówień bez złożoności WebSocket.
Zaimplementuj SSE w Nuxt. (1) Utwórz server/api/events.get.ts, który zwraca strumień SSE używając setResponseHeader(event, 'content-type', 'text/event-stream') i setResponseHeader(event, 'cache-control', 'no-cache'). Użyj createEventStream(event) z h3. Subskrybuj kanał Redis pub/sub dla aktualizacji zamówień i przesyłaj każdą aktualizację jako zdarzenie SSE z danymi JSON. Obsłuż rozłączenie klienta czyszcząc subskrypcję Redis. (2) Utwórz composables/useSSE.ts opakowujący EventSource z automatycznym ponownym łączeniem, typowanym parsowaniem wiadomości i czyszczeniem przy odmontowaniu komponentu. (3) Utwórz composables/useOrderUpdates.ts, który używa useSSE, filtruje zamówienia bieżącego użytkownika i reaktywnie aktualizuje store Pinia. (4) Pokaż powiadomienie toast gdy status zamówienia się zmieni. Przetestuj, że endpoint SSE odpowiada z poprawnymi nagłówkami i strumieniuje zdarzenia.
Oczekiwane wyjście: Trasa serwera SSE, dwa composables, integracja z Pinia i testy.
Scenariusz: Trzy aplikacje Nuxt współdzielą komponenty, composables i style. Potrzebujesz współdzielonej warstwy.
Utwórz warstwę Nuxt w layers/ui-kit/. (1) Skonfiguruj layers/ui-kit/nuxt.config.ts z defineNuxtConfig i eksportuj komponenty, composables i preset Tailwind. (2) Dodaj współdzielone komponenty w layers/ui-kit/components/: Button, Input, Select, Modal, Card, Badge, Avatar — każdy z propsami TypeScript, stylowaniem Tailwind i wariantami (size: sm/md/lg, variant: primary/secondary/outline/ghost). (3) Dodaj współdzielone composables: useToast(), useConfirmDialog(), useBreakpoint(). (4) Dodaj preset Tailwind w layers/ui-kit/tailwind.preset.ts z kolorami systemu projektowego, czcionkami i odstępami. (5) W aplikacji konsumenta rozszerz przez extends: ['./layers/ui-kit']. Zweryfikuj, że auto-importy działają dla komponentów i composables warstwy. Napisz test potwierdzający, że komponenty warstwy renderują się na stronie konsumenta.
Oczekiwane wyjście: Katalog warstwy z konfiguracją, 7 komponentami, 3 composables, presetem Tailwind i testem integracyjnym.
Scenariusz: Twoja aplikacja Nuxt potrzebuje typowo-bezpiecznych zapytań do bazy danych, migracji i seedowania.
Skonfiguruj Drizzle ORM z PostgreSQL w Nuxt. (1) Utwórz server/db/schema.ts z tabelami: users (id uuid, email unique, name, hashedPassword, role enum, createdAt), posts (id uuid, title, slug unique, content text, authorId references users, status enum draft/published/archived, publishedAt, createdAt), comments (id uuid, postId references posts, authorId references users, content text, createdAt). (2) Utwórz server/db/index.ts inicjalizujący klienta drizzle ze zmiennej środowiskowej. (3) Utwórz server/db/queries/ z typowanymi funkcjami: getUserByEmail(email), getPostsWithAuthor(page, pageSize), createPost(data), getPostBySlug(slug) z autorem i liczbą komentarzy. (4) Utwórz drizzle.config.ts dla migracji. (5) Utwórz skrypt seed w server/db/seed.ts z 10 użytkownikami, 50 postami i 200 komentarzami używając Faker. (6) Dodaj server/utils/db.ts zapewniający cache’owaną instancję bazy danych. Przetestuj zapytania na testowej bazie danych.
Oczekiwane wyjście: Plik schematu, funkcje zapytań, konfiguracja, skrypt seed i testy zapytań.
Scenariusz: Chcesz blog oparty na plikach Markdown z frontmatter, podświetlaniem kodu i spisem treści.
Skonfiguruj Nuxt Content v2 dla bloga. (1) Zainstaluj @nuxt/content i skonfiguruj z podświetlaniem kodu Shiki, kotwicami nagłówków i generowaniem TOC. (2) Utwórz content/blog/ z 3 przykładowymi postami używając frontmatter: title, description, author, date, tags array, image, draft boolean. (3) Utwórz pages/blog/index.vue listujący opublikowane posty posortowane malejąco po dacie z paginacją (10 na stronę). Pokaż tytuł, zajawkę, autora, datę i tagi. (4) Utwórz pages/blog/[...slug].vue dla poszczególnych postów z <ContentRenderer>, paskiem bocznym TOC, nawigacją prev/next i czasem czytania. (5) Utwórz components/content/ProseCode.vue do personalizacji bloków kodu z kopiowaniem do schowka. (6) Dodaj kanały RSS pod /api/rss.xml odpytując wszystkie opublikowane posty. Przetestuj listowanie bloga, renderowanie postów i wyjście RSS.
Oczekiwane wyjście: Konfiguracja Nuxt Content, przykładowe posty, strony bloga, niestandardowy komponent prose, trasa RSS i testy.
Scenariusz: Wdróż swoją aplikację Nuxt na Cloudflare Workers z bazą danych D1, cache’owaniem KV i magazynem R2.
Skonfiguruj Nuxt do wdrożenia na Cloudflare Workers. (1) Ustaw nitro: { preset: 'cloudflare-pages' } w nuxt.config. (2) Utwórz wrangler.toml z bindingiem bazy danych D1, namespace KV dla sesji i bukietem R2 dla uploadów. (3) Utwórz server/utils/cf.ts zapewniający typowany dostęp do bindingów Cloudflare przez event.context.cloudflare.env. (4) Utwórz middleware sesji w server/middleware/session.ts czytający/zapisujący dane sesji do KV z 24-godzinnym TTL. (5) Utwórz trasę uploadu plików w server/api/upload.post.ts przechowującą pliki w R2 i zwracającą publiczny URL. (6) Zaktualizuj zapytania bazodanowe aby używać D1 zamiast PostgreSQL. (7) Dodaj wrangler.toml do lokalnego rozwoju z --local D1. Testuj lokalnie z npx wrangler dev.
Oczekiwane wyjście: Konfiguracja Nitro, wrangler.toml, narzędzia bindingowe, middleware sesji, trasa uploadu i zapytania D1.
Scenariusz: Twoja aplikacja Nuxt ma zero testów. Potrzebujesz pokrycia dla komponentów, tras serwera i composables.
Skonfiguruj testowanie używając @nuxt/test-utils i Vitest. (1) Skonfiguruj vitest.config.ts z @nuxt/test-utils/module. (2) Utwórz narzędzia testowe w tests/utils/: renderPage(route) do renderowania stron z uwzględnieniem Nuxt, mockAuth(user?) dla stanu uwierzytelnionego, createTestDB() dla SQLite in-memory ze schematem. (3) Napisz testy komponentów dla 3 komponentów używając mountSuspended. (4) Napisz testy tras serwera używając $fetch z setup({ server: true }) dla 2 endpointów API. (5) Napisz testy composables montując komponent testowy konsumujący każdy composable. (6) Dodaj skrypty npm run test:unit i npm run test:integration. Skonfiguruj pokrycie z minimum 70% dla tras serwera.
Oczekiwane wyjście: Konfiguracja Vitest, narzędzia testowe, testy komponentów, testy tras serwera, testy composables i zaktualizowane skrypty.
Scenariusz: Twoja aplikacja Nuxt osiąga 60 punktów w Lighthouse. Przejścia między stronami są powolne, a bundle przekracza 1 MB.
Przeprowadź audyt i zoptymalizuj tę aplikację Nuxt pod kątem wydajności. (1) Uruchom npx nuxi analyze i zidentyfikuj chunki powyżej 50KB. Sprawdź, czy można je leniwie ładować lub zastąpić lżejszymi alternatywami. (2) Zamień wszystkie tagi <img> na <NuxtImg> z @nuxt/image dla responsywnych obrazów, leniwego ładowania poniżej fold i negocjacji formatu WebP/AVIF. (3) Włącz experimental.payloadExtraction dla osobnych plików payload. (4) Dodaj vite.build.rollupOptions.output.manualChunks do podzielenia kodu vendor na logiczne chunki. (5) Zaimplementuj <NuxtLoadingIndicator> z niestandardowym kolorem. (6) Dodaj useHead z podpowiedziami preload dla krytycznego CSS i czcionek. (7) Włącz cache’owanie routeRules dla stron statycznych. Zaraportuj wyniki Lighthouse przed i po. Cel: wydajność 90+, bundle poniżej 300KB początkowe.
Oczekiwane wyjście: Zaktualizowany nuxt.config, zamienione NuxtImg, konfiguracja podziału chunków i porównanie wydajności.
