@equinor/fusion-framework-vitest-plugin-react-app 0.2.0-next.0

package/CHANGELOG.md

@@ -0,0 +1,104 @@
+# @equinor/fusion-framework-vitest-plugin-react-app
+
+## 0.2.0-next.0
+
+### Minor Changes
+
+- 2836e0b: Add a `/config` entry-point exporting `defineProject`: a drop-in for Vitest's own `defineProject`, pre-wired with `appTestVitePlugin` and the `@vitest/browser-playwright`/`chromium` browser provider, so a consuming app's own `vitest.config.ts` needs no browser-provider boilerplate.
+
+  ```ts
+  import { defineProject } from "@equinor/fusion-framework-vitest-plugin-react-app/config";
+  import { name, version } from "./package.json" with { type: "json" };
+
+  export default defineProject({ test: { name: `${name}@${version}` } });
+  ```
+
+  `override` is deep-merged onto the default config via Vite's own `mergeConfig` (a plain object), or applied to the default config outright (a function receiving it) — for changes `mergeConfig` can't express, such as swapping `test.browser.provider` for a different `@vitest/browser-*` provider.
+
+  `@vitest/browser-playwright` and `playwright` are now explicit peer dependencies of the package.
+
+  Also fixes `appTestVitePlugin`'s `entrypoint` inference: when no `entrypoint` option is given, it now resolves from the Vitest project's own root (via `configResolved`) instead of `process.cwd()`, so each cookbook's `vitest.config.ts` no longer needs to pass `entrypoint` explicitly when run as part of a multi-project Vitest run.
+
+- 2836e0b: Add `@equinor/fusion-framework-vitest-plugin-react-app`: Vitest/`vitest-browser-react` helpers for testing a Fusion Framework React application inside a real, mock-backed application module scope — the same `FrameworkProvider` + `ModuleProvider` nesting `renderApp`/`createComponent` wire up in production, backed by `mockFramework` and `mockAppModules` (`@equinor/fusion-framework-app/mock`).
+
+  ```tsx
+  import { renderAppHook } from "@equinor/fusion-framework-vitest-plugin-react-app";
+  import { useAccessToken } from "@equinor/fusion-framework-react-app/msal";
+
+  const { result } = await renderAppHook(() =>
+    useAccessToken({ scopes: ["User.Read"] }),
+  );
+  await vi.waitFor(() => expect(result.current.pending).toBe(false));
+  ```
+
+  Highlights:
+
+  - `renderAppHook`/`renderAppComponent` — render a hook or component against the real `event`/`http`/`msal` module pipeline, with only the network boundary faked; the result carries a nested `fusion: { framework, app }` for driving a module directly after the initial render.
+  - `testApp` — a `vitest` `test` extended with `env`/`configure`/`app`/`render`/`renderHook` fixtures, for a test file whose cases share one mocked scope.
+  - `appTestVitePlugin` — a Vite plugin resolving an application's own manifest, config, and module-configurator (the same pipeline `ffc app build`/`ffc app dev` use) as virtual modules.
+  - A `/test` entry-point exporting `test`/`render`, pre-seeded from the resolved manifest/config/configure once `appTestVitePlugin` is registered — no per-test `env`/`configure` wiring.
+
+  Package documentation provides task-focused guides for setup, configuration, advanced fixtures,
+  module mocks, and troubleshooting so npm, GitHub, and retrieval clients use the same canonical
+  source as the VuePress site.
+
+### Patch Changes
+
+- e8aae1f: Internal: publish every package on the `next` pre-release tag so the whole framework can be installed as a coherent set.
+
+  Packages without their own changes are bumped only to receive a `-next.N` version and the `next` dist-tag on npm. Install with:
+
+  ```bash
+  pnpm add @equinor/fusion-framework-react-app@next
+  ```
+
+- 2836e0b: Fix `defineProject` not pre-transforming lazily/code-split-imported source (e.g. route
+  components reached only through dynamic `import()`), which could force Vite to reload the
+  page mid-test and fail the in-flight test file's import.
+
+  `defineProject`'s Vite config now sets `server.warmup.clientFiles: ['src/**/*.{ts,tsx}']`, so
+  all source under `src/` is transformed up front instead of on first request.
+
+- 2836e0b: Document `test.override(...)` for overriding a fixture (`configure`, `fusion`, etc.) within a
+  single test file or `describe` block, alongside the existing `test.extend(...)` guide, in the
+  package's "Advanced usage" doc (`docs/advanced.md`).
+- 2836e0b: Add a "Migrate an existing app" guide (`docs/migrating-an-existing-app.md`) covering how to
+  move a suite from `@testing-library/react`/jsdom/happy-dom onto this package: installing
+  Browser Mode, replacing hand-rolled `vi.mock`s of Fusion hooks with each module's `enable*Mock`
+  entry point, porting a hand-written mock HTTP server to `createRouterMiddleware`, composing a
+  router fixture with a domain-state fixture in one file, and updating renders/assertions to the
+  async `vitest-browser-react` API. Linked from the package README and from
+  `docs/overview.md` and `testing-choosing-a-layer.md`.
+- 2836e0b: Add a "Why Browser Mode is the default" guide (`docs/why-browser-mode.md`) explaining
+  the rationale for defaulting to real Chromium over DOM emulation (the documented React 19 peer
+  dependency crash in the previous renderer, plus the framework's real-module testing philosophy),
+  the actual performance tradeoff (a real browser is slower, not faster — this was a fidelity
+  choice, not a speed optimization), and how to bring your own renderer for a single test file by
+  composing `mockFramework`/`mockAppModules`/`FrameworkProvider`/`ModuleProvider` directly with a
+  different render function (e.g. `@testing-library/react` on `happy-dom`). Linked from the
+  package README and `docs/overview.md`.
+- Updated dependencies [e8aae1f]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+- Updated dependencies [2836e0b]
+  - @equinor/fusion-framework@8.1.0-next.0
+  - @equinor/fusion-framework-app@14.0.0-next.0
+  - @equinor/fusion-framework-cli@15.2.8-next.0
+  - @equinor/fusion-framework-module@6.1.3-next.0
+  - @equinor/fusion-framework-module-app@8.1.0-next.0
+  - @equinor/fusion-framework-react@9.0.0-next.0
+  - @equinor/fusion-framework-react-module@4.0.3-next.0
+  - @equinor/fusion-imports@2.0.3-next.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2022 Equinor
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,349 @@
+# @equinor/fusion-framework-vitest-plugin-react-app
+
+Vite plugin and Vitest helpers for testing Fusion Framework React applications inside a real,
+mock-backed application module scope — the same `FrameworkProvider` + `ModuleProvider` nesting
+`renderApp`/`createComponent` wire up in production, with the real `event`/`http`/`msal` module
+pipeline and only the network boundary faked.
+
+> **Note:** Requires `vitest-browser-react` (peer dependency) and Vitest's
+> [Browser Mode](https://vitest.dev/guide/browser/) configured for the project — these render
+> helpers mount real components in a real browser, not `happy-dom`/`jsdom`.
+
+Use this package when you need to:
+
+- **Render a component or hook against real application modules** — `useAppModule`,
+  `useAccessToken`, `useCurrentContext`, `useCurrentBookmark`, `useAppSetting`, and similar
+  hooks resolve for real, instead of being hand-mocked per test.
+- **Test against the application's own manifest, config, and module-configurator** — the same
+  resolution pipeline `ffc app build`/`ffc app dev` use, served as virtual modules by
+  `appTestVitePlugin`.
+- **Share seeded fixture defaults across a test file** — `testApp`, a `vitest` `test` extended
+  with `env`/`configure`/`app`/`render`/`renderHook` fixtures, instead of repeating options on
+  every call. Each test still gets its own fresh `fusion`/`app` instances; only the seeded
+  defaults are shared, not state between tests.
+
+## Installation
+
+```sh
+pnpm add -D vitest playwright @vitest/browser-playwright vitest-browser-react \
+  @equinor/fusion-framework-vitest-plugin-react-app
+pnpm exec playwright install chromium
+```
+
+React, React DOM, RxJS, and Vite are peer dependencies normally supplied by the app.
+
+## Documentation
+
+| Task | Guide |
+| --- | --- |
+| Understand the package and choose a subject | [Overview](docs/overview.md) |
+| Install, configure, and run the first app test | [Getting started](docs/getting-started.md) |
+| Override Vitest defaults or resolve non-standard app files | [Configuration](docs/configuration.md) |
+| Compose fixtures, explicit render options, and app lifecycle tests | [Advanced usage](docs/advanced.md) |
+| Diagnose setup, browser, app-resolution, and network failures | [Troubleshooting](docs/troubleshooting.md) |
+| Seed authentication, context, bookmarks, feature flags, HTTP, analytics, and telemetry | [Module mocks](docs/module-mocks.md) |
+| Understand the Browser Mode default or choose another renderer | [Why Browser Mode is the default](docs/why-browser-mode.md) |
+| Move an existing `@testing-library/react`/jsdom suite onto this package | [Migrate an existing app](docs/migrating-an-existing-app.md) |
+| Choose between app, framework, module, HTTP, and runner-level tests | [Choose a testing layer](../../framework/docs/testing-choosing-a-layer.md) |
+
+## Overview
+
+Any hook or component that reads from the application module scope — `useAppModule`,
+`useAccessToken`, `useCurrentContext`, `useCurrentBookmark`, `useAppSetting`, and so on — or
+from the parent framework via `useFramework`, needs to run inside the same provider nesting
+`renderApp`/`createComponent` wire up in production: a `FrameworkProvider` (the parent Fusion
+instance) around a `ModuleProvider` (the app's own modules).
+
+`renderAppHook` and `renderAppComponent` build that nesting for you, using `mockFramework`
+(`@equinor/fusion-framework/mock`) and `mockAppModules` (`@equinor/fusion-framework-app/mock`) —
+the **real** `event`/`http`/`msal` module pipeline. Only requests a seeded middleware answers
+are faked; a request with no matching middleware still reaches the real network. This means:
+
+- MSAL signs in a default "Test User" with zero configuration — `useAccessToken`/`useToken`
+  resolve a real, structurally-valid (unsigned) JWT out of the box.
+- `event` dispatches and listens for real `FrameworkEvent`s.
+- Anything that talks to an HTTP endpoint (e.g. an app's own manifest, settings) is answered
+  by a mock client rather than a real network call — see each hook's own docs for what's
+  pre-wired versus what you need to seed yourself (e.g. via `enableBookmarkMock`,
+  `enableContextMock`, `enableFeatureFlagMock`, or a `configurator.http.addMiddleware(...)`
+  router).
+
+Use `renderAppHook` for a hook in isolation; use `renderAppComponent` when you need to assert
+on rendered output (e.g. loading/error states, DOM structure); use `testApp` or the `/test`
+entry-point's `test`/`render` when several cases in a file share one seeded scope.
+
+## Entry points
+
+- **`@equinor/fusion-framework-vitest-plugin-react-app`** — `appTestVitePlugin`,
+  `renderAppComponent`, `renderAppHook`, `testApp`. No app-specific resolution; you pass
+  `env`/`configure` yourself.
+- **`@equinor/fusion-framework-vitest-plugin-react-app/test`** — `test`, `render`. Require
+  `appTestVitePlugin` registered in `vitest.config.ts`; `env`/`configure` are resolved
+  automatically from the application's own manifest, config, and module-configurator.
+- **`@equinor/fusion-framework-vitest-plugin-react-app/config`** — `defineProject`. Registers
+  `appTestVitePlugin`, headless Playwright/Chromium, test-file inclusion, and lazy-import
+  warmup while accepting ordinary Vitest configuration overrides.
+
+## Quick start
+
+Use the browser-ready project config in your app's `vitest.config.ts`:
+
+```ts
+import { defineProject } from '@equinor/fusion-framework-vitest-plugin-react-app/config';
+
+export default defineProject();
+```
+
+Then use the pre-seeded `test` fixture — no per-test `env`/`configure` wiring:
+
+```tsx
+import { expect } from 'vitest';
+import { test } from '@equinor/fusion-framework-vitest-plugin-react-app/test';
+import { App } from '../App';
+
+test('renders the app', async ({ render }) => {
+  const screen = await render(<App />);
+  await expect.element(screen.getByRole('heading')).toBeVisible();
+});
+```
+
+Or, in a plain `describe`/`it` file, the equivalent `render` function:
+
+```tsx
+import { describe, expect, it } from 'vitest';
+import { render } from '@equinor/fusion-framework-vitest-plugin-react-app/test';
+import { App } from '../App';
+
+describe('App', () => {
+  it('renders the app', async () => {
+    const { getByRole } = await render(<App />);
+    await expect.element(getByRole('heading')).toBeVisible();
+  });
+});
+```
+
+## renderAppHook
+
+Renders a hook inside a real, mock-backed application module scope.
+
+**Signature:**
+
+```ts
+function renderAppHook<Result, Props = undefined, TModules = unknown, TEnv extends AppEnv = AppEnv>(
+  render: (initialProps?: Props) => Result,
+  options?: {
+    configure?: AppMockConfigureFn<TModules, TEnv>;
+    env?: TEnv;
+    fusion?: Fusion;
+  } & Omit<RenderHookOptions<Props>, 'wrapper'>,
+): Promise<RenderHookResult<Result, Props> & { fusion: { framework: Fusion; app: AppModulesInstance<TModules> } }>;
+```
+
+| Option      | Description                                                                                                        |
+| ----------- | -------------------------------------------------------------------------------------------------------------------|
+| `configure` | Callback forwarded to `mockAppModules` for seeding app-scope modules (bookmark, context, feature-flag, msal, etc.) |
+| `env`       | The application environment (manifest); defaults to a generic standalone `test-app`                                |
+| `fusion`    | The parent Fusion instance; defaults to a fresh `mockFramework` instance serving this app's own manifest           |
+
+Any other `renderHook` option (e.g. `initialProps`) is forwarded as-is. The result carries the
+usual `renderHook` return values (`result`, `rerender`, `unmount`) plus `fusion` — the same
+instances the hook rendered against — for driving a module the hook itself doesn't return.
+
+### Basic usage
+
+```tsx
+import { renderAppHook } from '@equinor/fusion-framework-vitest-plugin-react-app';
+import { useAccessToken } from '@equinor/fusion-framework-react-app/msal';
+
+test('resolves an access token', async () => {
+  const { result } = await renderAppHook(() => useAccessToken({ scopes: ['User.Read'] }));
+  await vi.waitFor(() => expect(result.current.pending).toBe(false));
+  expect(result.current.token).toBeDefined();
+});
+```
+
+### Sign in a named user
+
+Pass `configure` to reach the msal mock's builder before the hook renders:
+
+```tsx
+import { renderAppHook } from '@equinor/fusion-framework-vitest-plugin-react-app';
+import { useCurrentAccount } from '@equinor/fusion-framework-react-app/msal';
+
+test('reads the configured account', async () => {
+  const { result } = await renderAppHook(() => useCurrentAccount(), {
+    configure: (configurator) => configurator.msal.setAccount({ name: 'Ada Lovelace' }),
+  });
+  expect(result.current).toMatchObject({ name: 'Ada Lovelace' });
+});
+```
+
+### Reuse a pre-built parent Fusion instance
+
+Build the `fusion` instance yourself when a test needs to pre-configure parent-level modules
+(`http`, `context`, `serviceDiscovery`) or share one instance across multiple render calls:
+
+```tsx
+import { mockFramework } from '@equinor/fusion-framework/mock';
+import { enableAppManifestMock } from '@equinor/fusion-framework-app/mock';
+import type { AppModule } from '@equinor/fusion-framework-module-app';
+import { renderAppHook } from '@equinor/fusion-framework-vitest-plugin-react-app';
+import { useAccessToken, useCurrentAccount } from '@equinor/fusion-framework-react-app/msal';
+
+const env = { manifest: { appKey: 'test-app', displayName: 'Test App', description: '', type: 'standalone' as const } };
+
+test('shares one fusion instance across two renders', async () => {
+  const fusion = await mockFramework<[AppModule]>((configurator) =>
+    enableAppManifestMock(configurator, env),
+  );
+
+  const { result: a } = await renderAppHook(() => useAccessToken({ scopes: ['User.Read'] }), { fusion });
+  const { result: b } = await renderAppHook(() => useCurrentAccount(), { fusion });
+});
+```
+
+## renderAppComponent
+
+Renders a component inside the same real, mock-backed application module scope as
+`renderAppHook`. Use this when you need to assert on rendered output rather than a hook's
+return value — e.g. a component with its own loading/error states.
+
+**Signature:**
+
+```ts
+function renderAppComponent<TModules = unknown, TEnv extends AppEnv = AppEnv>(
+  ui: ReactElement,
+  options?: {
+    configure?: AppMockConfigureFn<TModules, TEnv>;
+    env?: TEnv;
+    fusion?: Fusion;
+  } & Omit<RenderOptions, 'wrapper'>,
+): Promise<RenderResult & { fusion: { framework: Fusion; app: AppModulesInstance<TModules> } }>;
+```
+
+Options are the same shape as `renderAppHook`'s — `configure`, `env`, `fusion` — plus any other
+`vitest-browser-react` `render` option. The result carries the usual `render` return values
+(`getByText`, `container`, `unmount`, ...) plus `fusion` — nested rather than spread directly
+onto the result, so `vitest-browser-react`'s own return shape stays free to evolve without ever
+colliding with it. `fusion.app` is the same application module instance the rendered component
+reads through `useAppModule`/`useAppModules`, and `fusion.framework` is the parent Fusion
+instance. Drive a module directly through `fusion.app` to exercise a state change after the
+initial render, without hand-wiring `mockAppModules`/`ModuleProvider`:
+
+```tsx
+import { enableContextMock } from '@equinor/fusion-framework-module-context/mock';
+import type { ContextModule } from '@equinor/fusion-framework-module-context';
+import { act } from 'react';
+import { renderAppComponent } from '@equinor/fusion-framework-vitest-plugin-react-app';
+
+test('reacts when the current context switches', async () => {
+  const { getByText, fusion } = await renderAppComponent<[ContextModule]>(<App />, {
+    configure: (configurator) =>
+      enableContextMock(configurator, (mock) => mock.setCurrentContext(projectA)),
+  });
+
+  await act(() => fusion.app.context.setCurrentContextByIdAsync(projectB.id));
+  await expect.element(getByText(/project-b/)).toBeVisible();
+});
+```
+
+### Example: asserting loading and error states
+
+```tsx
+import { mockFramework } from '@equinor/fusion-framework/mock';
+import { enableAppManifestMock } from '@equinor/fusion-framework-app/mock';
+import type { AppManifest, AppModule } from '@equinor/fusion-framework-module-app';
+import { renderAppComponent } from '@equinor/fusion-framework-vitest-plugin-react-app';
+import { Apploader } from '@equinor/fusion-framework-react-app/apploader';
+
+test('mounts the child app once its script loads', async () => {
+  const manifest: AppManifest = {
+    appKey: 'child-app',
+    displayName: 'Child App',
+    description: 'A child application',
+    type: 'standalone',
+    build: { version: '1.0.0', entryPoint: 'child-script.ts', assetPath: '' },
+  };
+  const fusion = await mockFramework<[AppModule]>((configurator) =>
+    enableAppManifestMock(configurator, { manifest }, someFixturesUri),
+  );
+
+  const { container } = await renderAppComponent(<Apploader appKey="child-app" />, { fusion });
+
+  // the loading state renders synchronously, before the script's dynamic import resolves
+  expect(container.textContent).toContain('Loading child-app');
+  await vi.waitFor(() => expect(container.textContent).toContain('mounted: child-app'));
+});
+```
+
+## testApp
+
+`vitest`'s `test`, extended with an application module scope fixture — an alternative to
+`renderAppComponent`/`renderAppHook` for a test file whose cases share one mocked scope:
+`env`/`configure` become suite-level concerns, overridden once per file (or per `describe`
+block) with `testApp.extend(...)`, rather than an options object repeated on every call.
+`fusion`/`app` resolve lazily — a test that only destructures `app` never pays for rendering
+anything, and one that only destructures `render`/`renderHook` gets the same mocked scope
+wired in automatically.
+
+```tsx
+import { testApp } from '@equinor/fusion-framework-vitest-plugin-react-app';
+
+testApp('resolves current context', async ({ app, render }) => {
+  const screen = await render(<App />);
+  expect(app.context).toBeDefined();
+});
+```
+
+Seed a module for every test in a suite:
+
+```tsx
+describe('with a seeded context module', () => {
+  const test = testApp.extend('configure', { injected: true }, () =>
+    (configurator) => enableContextMock(configurator, (mock) => mock.setCurrentContext(projectA)),
+  );
+
+  test('starts on the seeded context', async ({ render }) => {
+    const screen = await render(<App />);
+    await expect.element(screen.getByText(projectA.title)).toBeVisible();
+  });
+});
+```
+
+## appTestVitePlugin
+
+A plain Vite plugin — Vitest configs are Vite configs, so this registers directly in your own
+`vitest.config.ts`, no CLI command required. It serves an application's manifest/config
+(resolved the same way `ffc app build`/`ffc app dev` do) and its own module-configurator
+export as virtual modules, so the `/test` entry-point's `test`/`render` need no per-test
+`env`/`configure` wiring.
+
+```ts
+appTestVitePlugin({
+  entrypoint?: string; // defaults to the resolved Vite/Vitest project root
+  manifest?: string | AppManifestFn;
+  config?: string | AppConfigFn;
+  configure?: string; // defaults to the first of src/config.ts, src/config.tsx, src/config.js
+});
+```
+
+`entrypoint`, `manifest`, and `config` are forwarded to the same manifest/config resolution
+`ffc app build`/`ffc app dev` use (a base manifest generated from `package.json`, merged with a
+local `app.manifest.ts` if one exists, plus `app.config.ts` for endpoints). `configure` points
+at the application's module-configurator file — unlike `manifest`/`config`, it must be a real
+file on disk, since it's re-exported as live application code into the test bundle rather than
+JSON-serialized data. An explicitly requested `manifest`/`config`/`configure` file that doesn't
+exist throws `FileNotFoundError`; the convention-based lookups fail silently and fall back to
+defaults instead.
+
+## Notes
+
+- Every render/hook helper is `async` — always `await` it, since the mocked application module
+  scope (app manifest, module initialization) resolves asynchronously before the first render.
+- Seeding a module beyond the default set (bookmark, context, feature-flag) requires its own
+  mock enabler passed through `configure` — e.g. `enableBookmarkMock`, `enableContextMock`,
+  `enableFeatureFlagMock` from that module's own `/mock` sub-path.
+- `msal` ships enabled by default with a signed-in "Test User" — no `configure` needed unless
+  a test cares about a specific account or a signed-out state.
+- Prefer these helpers over hand-wiring `mockFramework`, `mockAppModules`, `FrameworkProvider`,
+  and `ModuleProvider` directly in every test.

package/dist/esm/app-test.js

@@ -0,0 +1,9 @@
+export { renderAppHook, } from './render-app-hook';
+export { renderAppComponent, } from './render-app-component';
+export { testApp } from './test-app';
+// `test`/`render` import virtual modules only served once `appTestVitePlugin`
+// (@equinor/fusion-framework-vitest-plugin-react-app) is registered — using any export from
+// this module requires the plugin registered in your `vitest.config.ts` `plugins`.
+export { test } from './test';
+export { render } from './render';
+//# sourceMappingURL=app-test.js.map

package/dist/esm/app-test.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"app-test.js","sourceRoot":"","sources":["../../src/app-test.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,aAAa,GAGd,MAAM,mBAAmB,CAAC;AAC3B,OAAO,EACL,kBAAkB,GAGnB,MAAM,wBAAwB,CAAC;AAChC,OAAO,EAAE,OAAO,EAAE,MAAM,YAAY,CAAC;AAGrC,8EAA8E;AAC9E,4FAA4F;AAC5F,mFAAmF;AACnF,OAAO,EAAE,IAAI,EAAE,MAAM,QAAQ,CAAC;AAC9B,OAAO,EAAE,MAAM,EAAE,MAAM,UAAU,CAAC"}

package/dist/esm/define-project.js

@@ -0,0 +1,68 @@
+import { playwright } from '@vitest/browser-playwright';
+import { defineProject as defineVitestProject, mergeConfig, } from 'vitest/config';
+import { appTestVitePlugin } from './index.js';
+/**
+ * Builds a ready-to-export Vitest project config for testing a Fusion Framework React app:
+ * registers {@link appTestVitePlugin} (with its own defaults) and wires up Vitest browser mode
+ * with the Playwright/`chromium` provider, so a consuming app's own `vitest.config.ts` needs no
+ * browser-provider boilerplate of its own.
+ *
+ * @remarks
+ * Drop-in replacement for Vitest's own `defineProject` — same `export default`, just pre-wired.
+ * Playwright/`chromium` is only the *default* — pass `override` to change or replace anything
+ * (e.g. `test.name`, or swap `test.browser.provider` for a different `@vitest/browser-*`
+ * provider) without hand-rolling `appTestVitePlugin`'s own wiring.
+ *
+ * @example
+ * ```ts
+ * import { defineProject } from '@equinor/fusion-framework-vitest-plugin-react-app/config';
+ * import { name, version } from './package.json' with { type: 'json' };
+ *
+ * export default defineProject({ test: { name: `${name}@${version}` } });
+ * ```
+ *
+ * @example
+ * Overriding the browser provider:
+ * ```ts
+ * import { webdriverio } from '@vitest/browser-webdriverio';
+ *
+ * export default defineProject({ test: { browser: { provider: webdriverio() } } });
+ * ```
+ *
+ * @param override - Deep-merged onto the default config (a plain object), or applied to it
+ * outright (a function receiving the default config); see {@link AppTestConfigOverride}.
+ * @returns A Vitest project config, ready to `export default`.
+ */
+export const defineProject = (override) => {
+    const defaults = {
+        plugins: [appTestVitePlugin()],
+        test: {
+            include: ['src/**/*.{test,spec}.{ts,tsx}'],
+            browser: {
+                enabled: true,
+                provider: playwright(),
+                headless: true,
+                instances: [{ browser: 'chromium' }],
+            },
+        },
+        // pre-transforms all source up front so deps only reached via lazy/code-split imports
+        // (e.g. route components) are discovered before the first test request, not mid-run —
+        // the latter forces Vite to reload the page and fails the in-flight test file import
+        server: { warmup: { clientFiles: ['src/**/*.{ts,tsx}'] } },
+        // same reasoning as `server.warmup` above, but for the esbuild dep scanner: without this,
+        // its default entry detection can miss code-split route files entirely, so a package only
+        // ever imported from one of those (e.g. react-router's own deps) is discovered mid-run
+        // instead of up front — statically crawling every source file (which esbuild's scanner
+        // follows through dynamic imports too) avoids that with no per-package name needed
+        optimizeDeps: { entries: ['src/**/*.{ts,tsx}'] },
+    };
+    // a function replaces the config outright; a plain object deep-merges onto it via Vite's own mergeConfig
+    const resolved = typeof override === 'function'
+        ? override(defaults)
+        : override
+            ? mergeConfig(defaults, override)
+            : defaults;
+    return defineVitestProject(resolved);
+};
+export default defineProject;
+//# sourceMappingURL=define-project.js.map

package/dist/esm/define-project.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"define-project.js","sourceRoot":"","sources":["../../src/define-project.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,4BAA4B,CAAC;AACxD,OAAO,EACL,aAAa,IAAI,mBAAmB,EACpC,WAAW,GAEZ,MAAM,eAAe,CAAC;AAEvB,OAAO,EAAE,iBAAiB,EAAE,MAAM,YAAY,CAAC;AAW/C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG,CAAC,QAAgC,EAAuB,EAAE;IACrF,MAAM,QAAQ,GAAwB;QACpC,OAAO,EAAE,CAAC,iBAAiB,EAAE,CAAC;QAC9B,IAAI,EAAE;YACJ,OAAO,EAAE,CAAC,+BAA+B,CAAC;YAC1C,OAAO,EAAE;gBACP,OAAO,EAAE,IAAI;gBACb,QAAQ,EAAE,UAAU,EAAE;gBACtB,QAAQ,EAAE,IAAI;gBACd,SAAS,EAAE,CAAC,EAAE,OAAO,EAAE,UAAU,EAAE,CAAC;aACrC;SACF;QACD,sFAAsF;QACtF,sFAAsF;QACtF,qFAAqF;QACrF,MAAM,EAAE,EAAE,MAAM,EAAE,EAAE,WAAW,EAAE,CAAC,mBAAmB,CAAC,EAAE,EAAE;QAC1D,0FAA0F;QAC1F,0FAA0F;QAC1F,uFAAuF;QACvF,uFAAuF;QACvF,mFAAmF;QACnF,YAAY,EAAE,EAAE,OAAO,EAAE,CAAC,mBAAmB,CAAC,EAAE;KACjD,CAAC;IACF,yGAAyG;IACzG,MAAM,QAAQ,GACZ,OAAO,QAAQ,KAAK,UAAU;QAC5B,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC;QACpB,CAAC,CAAC,QAAQ;YACR,CAAC,CAAE,WAAW,CAAC,QAAQ,EAAE,QAAQ,CAAyB;YAC1D,CAAC,CAAC,QAAQ,CAAC;IACjB,OAAO,mBAAmB,CAAC,QAAQ,CAAC,CAAC;AACvC,CAAC,CAAC;AAEF,eAAe,aAAa,CAAC"}

package/dist/esm/index.js

@@ -0,0 +1,99 @@
+import { existsSync } from 'node:fs';
+import { resolve } from 'node:path';
+import { FileNotFoundError } from '@equinor/fusion-imports';
+import { resolveAppTestEnv } from './resolve-app-test-env.js';
+const ENV_MODULE_ID = 'virtual:fusion-app-test-env';
+const CONFIGURE_MODULE_ID = 'virtual:fusion-app-test-configure';
+const RESOLVED_ENV_MODULE_ID = `\0${ENV_MODULE_ID}`;
+const RESOLVED_CONFIGURE_MODULE_ID = `\0${CONFIGURE_MODULE_ID}`;
+const DEFAULT_CONFIGURE_CANDIDATES = ['src/config.ts', 'src/config.tsx', 'src/config.js'];
+/**
+ * Vite plugin serving an application's manifest/config (resolved the same way `ffc app build`/
+ * `ffc app dev` do) and its own module-configurator export as virtual modules, so
+ * `@equinor/fusion-framework-vitest-plugin-react-app/test`'s `test`/`render` need no per-test
+ * `env`/`configure` wiring.
+ *
+ * @remarks
+ * A plain Vite plugin — Vitest configs are Vite configs, so this registers directly in your
+ * own `vitest.config.ts`, no CLI command required:
+ * ```ts
+ * import { defineConfig } from 'vitest/config';
+ * import { appTestVitePlugin } from '@equinor/fusion-framework-vitest-plugin-react-app';
+ *
+ * export default defineConfig({
+ *   plugins: [appTestVitePlugin()],
+ *   // ...your own browser-mode config
+ * });
+ * ```
+ * Exposes two virtual modules: `virtual:fusion-app-test-env` (`manifest`/`config`, as JSON) and
+ * `virtual:fusion-app-test-configure` (a re-export of the resolved `configure` module, or
+ * `undefined` if none exists). Not intended to be imported directly by application code.
+ *
+ * @param options - Resolution options; `entrypoint` defaults to the current working directory.
+ * @returns A Vite plugin instance.
+ */
+export const appTestVitePlugin = (options) => {
+    const explicitEntrypoint = options?.entrypoint;
+    let entrypoint = explicitEntrypoint;
+    let configureModulePath = explicitEntrypoint
+        ? resolveConfigureModulePath(explicitEntrypoint, options?.configure)
+        : undefined;
+    return {
+        name: 'fusion:app-test',
+        configResolved(config) {
+            // Vitest resolves each workspace project's root from its config file, which identifies the app containing src/index.ts.
+            entrypoint ??= config.root;
+            configureModulePath ??= resolveConfigureModulePath(entrypoint, options?.configure);
+        },
+        resolveId(id) {
+            // claim only our two virtual specifiers, leave everything else to the normal resolvers
+            if (id === ENV_MODULE_ID)
+                return RESOLVED_ENV_MODULE_ID;
+            // second virtual specifier, same rule as above
+            if (id === CONFIGURE_MODULE_ID)
+                return RESOLVED_CONFIGURE_MODULE_ID;
+            return null;
+        },
+        async load(id) {
+            // serves manifest/config resolved lazily here, not at plugin-creation time, so options.entrypoint changes between test runs are respected
+            if (id === RESOLVED_ENV_MODULE_ID) {
+                const { manifest, config } = await resolveAppTestEnv({ ...options, entrypoint });
+                return [
+                    `export const manifest = ${JSON.stringify(manifest)};`,
+                    `export const config = ${JSON.stringify(config)};`,
+                ].join('\n');
+            }
+            // no conventional module means the app registers no extra modules, same as omitting `configure` from `makeComponent`
+            if (id === RESOLVED_CONFIGURE_MODULE_ID) {
+                return configureModulePath
+                    ? `export { default as configure } from ${JSON.stringify(configureModulePath)};`
+                    : 'export const configure = undefined;';
+            }
+            return null;
+        },
+    };
+};
+/**
+ * Resolves the app's module-configurator file: the explicit `file` if given, otherwise the
+ * first existing candidate in {@link DEFAULT_CONFIGURE_CANDIDATES}.
+ *
+ * @throws {@link FileNotFoundError} If an explicitly requested `file` does not exist — unlike
+ * the convention-based lookup, a typo here should fail loudly instead of silently running the
+ * test suite without the application's modules.
+ */
+const resolveConfigureModulePath = (cwd, file) => {
+    // an explicit path is a user request, not a convention lookup, so a typo must fail loudly
+    if (file) {
+        const resolved = resolve(cwd, file);
+        // fail fast rather than silently falling back to "no configurator"
+        if (!existsSync(resolved)) {
+            throw new FileNotFoundError(`Configure module not found: ${resolved}`);
+        }
+        return resolved;
+    }
+    // first candidate that exists wins; none existing is a valid "no configurator" state
+    const found = DEFAULT_CONFIGURE_CANDIDATES.find((candidate) => existsSync(resolve(cwd, candidate)));
+    return found ? resolve(cwd, found) : undefined;
+};
+export default appTestVitePlugin;
+//# sourceMappingURL=index.js.map