Configures both previously-empty test runners (vitest.config.ts, playwright.config.ts) and adds the typed lib/api client layer (axios + interceptors), the session-cookie plumbing (lib/auth), TanStack Query infrastructure (lib/query, providers), and a real sign-in flow consuming supporthub-api's own login (010-identity-auth) - the true foundation every other user story in this feature depends on. Two structural fixes to the existing scaffold, both found only by running the app rather than by inspection: middleware.ts belongs at src/middleware.ts under this project's src/ layout, not the repo root; and next.config.mjs's output:'export' is incompatible with Next.js Middleware outright (the dev server refuses to start it), so this app now runs as a standard Next.js server - confirmed with the user before making that deployment-mode change. Verified end-to-end with a real, locally-running supporthub-api: all 5 Playwright scenarios (unauthenticated redirect, sign-in, wrong-password generic error, non-admin role gating, sign-out) pass against a live backend, not a mock. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
24 lines
796 B
TypeScript
24 lines
796 B
TypeScript
import { defineConfig, devices } from '@playwright/test';
|
|
|
|
export default defineConfig({
|
|
testDir: './tests/e2e',
|
|
// Serial, not fullyParallel: against a Next.js DEV server, concurrent first-hit requests to
|
|
// different routes contend on that dev server's own on-demand page compilation, causing
|
|
// response-time flakiness unrelated to the app itself. A production build (`next build &&
|
|
// next start`) doesn't have this cold-compile-per-route behavior; revisit if E2E ever runs
|
|
// against one.
|
|
workers: 1,
|
|
retries: process.env.CI ? 2 : 0,
|
|
reporter: 'list',
|
|
use: {
|
|
baseURL: process.env.NEXT_PUBLIC_APP_URL ?? 'http://localhost:3000',
|
|
trace: 'on-first-retry',
|
|
},
|
|
projects: [
|
|
{
|
|
name: 'chromium',
|
|
use: { ...devices['Desktop Chrome'] },
|
|
},
|
|
],
|
|
});
|