@equinor/fusion-framework 8.1.0 → 8.1.1

package/docs/testing-api.md

@@ -1,25 +0,0 @@
-# API
-
-| Export | Owner | Purpose |
-| --- | --- | --- |
-| `mockFramework<TModules>(configure?)` | `/mock` | Build and initialize a framework instance for a test |
-| `FrameworkMockConfigurator<TModules>` | `/mock` | `FrameworkConfigurator` whose outward boundaries are mocked, exposing `msal`, `serviceDiscovery`, `http` and `context` |
-| `enableMsalMock(configurator, configure?)` | `-module-msal/mock` | Register the auth module with an in-process MSAL client |
-| `msalMockModule` | `-module-msal/mock` | The auth module with a mock client, for manual registration |
-| `MsalMockConfigurator` | `-module-msal/mock` | `MsalConfigurator` backed by a mock client (`setAccount`, `setClient`, …) |
-| `MsalMockClient(config)` | `-module-msal/mock` | Build the in-process MSAL client on its own, from the same `MsalClientConfig` as `MsalClient` |
-| `createMsalMockClient(config, user?)` | `-module-msal/mock` | Convenience alias for `new MsalMockClient(config)`, optionally signing a user in |
-| `createMockToken(claims?)` | `-module-msal/mock` | Mint a deterministic JWT |
-| `mockServiceDiscovery(configurator, options?, configure?)` | `-module-service-discovery/mock` | Replace service discovery with an in-memory registry |
-| `enableServiceDiscoveryMock(configurator, configure?)` | `-module-service-discovery/mock` | Register the discovery module with an in-memory registry |
-| `ServiceDiscoveryMockConfigurator` | `-module-service-discovery/mock` | `ServiceDiscoveryConfigurator` that builds an in-memory registry (`setBaseUri`, `addService`, …) |
-| `ServiceDiscoveryMockClient(options?)` | `-module-service-discovery/mock` | Build the in-memory discovery client on its own |
-| `defaultServiceDiscoveryMockServices` | `-module-service-discovery/mock` | Baseline services a Fusion app resolves at start-up |
-| `createMockService(service, baseUri?)` | `-module-service-discovery/mock` | Expand a sparse service declaration into a full `Service` |
-| `configureHttp(configure)` | `-module-http` | Build a module config that pairs `configureClient`/`configureHttpClient` and `addMiddleware` for `configurator.addConfig(...)` — the real module, no mock client |
-| `createOpenApiMockMiddleware(mock)` | `-module-http/mock` | Adapt an `@equinor/fusion-openapi-mock` instance into an `HttpMiddleware`, for use with `configurator.http.addMiddleware(...)` |
-| `enableContextMock(configurator, configure?)` | `-module-context/mock` | Register the context module with an in-memory seeded pool |
-| `contextMockModule` | `-module-context/mock` | The context module with a mock client, for manual registration |
-| `ContextMockConfigurator` | `-module-context/mock` | `ContextModuleConfigurator` backed by in-memory context items (`setCurrentContext`, `setContexts`, `addContext`, `setRelatedContexts`, `setResolver`) |
-
-Module-owned exports are re-exported from `@equinor/fusion-framework/mock` for convenience; importing them from their own package is equally valid.

package/docs/testing-choosing-a-layer.md

@@ -1,90 +0,0 @@
-# Choose a Fusion testing layer
-
-Start with the smallest layer that initializes the production behavior the test needs. Fusion
-test utilities substitute external boundaries; Vitest still owns tests, assertions, lifecycle
-hooks, spies, timers, coverage, and general module mocking.
-
-## Which import should I use?
-
-| Testing intent | Start with | Import |
-| --- | --- | --- |
-| Pure function or framework-independent hook | Standard Vitest | `vitest` |
-| React hook that consumes app modules | `renderAppHook` | `@equinor/fusion-framework-vitest-plugin-react-app` |
-| React component, route, or complete Fusion app | Extended `test` and `render` fixture | `@equinor/fusion-framework-vitest-plugin-react-app/test` |
-| Reusable app fixture without automatic app-file resolution | `testApp` | `@equinor/fusion-framework-vitest-plugin-react-app` |
-| Application module configuration without React | `mockAppModules` | `@equinor/fusion-framework-app/mock` |
-| Parent framework or portal-level modules | `mockFramework` | `@equinor/fusion-framework/mock` |
-| One module in a bespoke module graph | That module's `enable*Mock` helper | `@equinor/fusion-framework-module-*/mock` |
-| Named HTTP clients and a few deterministic responses | `configurator.http.addMiddleware` | Real HTTP configurator |
-| Many HTTP operations described by OpenAPI | `createOpenApiMockMiddleware` | `@equinor/fusion-framework-module-http/mock` |
-| One method call, timer, global, or JavaScript module | Vitest's `vi` APIs | `vitest` |
-
-## React app tests
-
-Use `@equinor/fusion-framework-vitest-plugin-react-app/test` for the normal application path.
-Its `test` and `render` exports resolve the app's manifest, `app.config.ts`, and module
-configurator, then initialize a fresh framework and app scope for each test.
-
-```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();
-});
-```
-
-Use the root entry point's `renderAppHook`, `renderAppComponent`, or `testApp` only when the
-test should provide `env`, `configure`, or a parent `fusion` instance explicitly. See the
-[`@equinor/fusion-framework-vitest-plugin-react-app` documentation](../../vitest-plugin/react-app/README.md).
-
-## Framework and module tests
-
-Use `mockFramework` when code consumes the parent framework directly or when the test needs
-to seed several built-in framework modules together:
-
-```ts
-import { mockFramework } from '@equinor/fusion-framework/mock';
-
-const fusion = await mockFramework((configurator) => {
-  configurator.msal.setAccount({ name: 'Ada Lovelace' });
-  configurator.context.setCurrentContext({
-    id: 'project-a',
-    title: 'Project A',
-    type: { id: 'ProjectMaster' },
-    value: {},
-  });
-  configurator.serviceDiscovery.addService({ key: 'catalog' });
-});
-```
-
-Use a module-owned `/mock` entry point when assembling a custom module graph or testing the
-module without the standard framework set. Module mocks keep the real provider,
-configurator, validation, and lifecycle; only the client or data source that leaves the
-process is substituted.
-
-## Choosing how to fake data
-
-| Need | Preferred boundary | Why |
-| --- | --- | --- |
-| One known context item | `enableContextMock` | Seeds domain data without transport setup |
-| Context service integration | HTTP middleware | Exercises service discovery, HTTP, and context client behavior together |
-| One or two HTTP routes | Hand-written `HttpMiddleware` | Keeps the response behavior explicit |
-| An API described by OpenAPI | `createOpenApiMockMiddleware` | Generates deterministic responses for the whole specification |
-| An individual client call | `vi.spyOn` | Uses the test runner's call assertions and reset semantics |
-
-An HTTP middleware handles only matching requests. Calling `next(uri, init)` continues to the
-next middleware and eventually the real network. Tests intended to be fully offline should
-fail or answer every request they expect.
-
-## Related package documentation
-
-- [Framework mock usage](testing.md)
-- [Framework mock design](testing-design.md)
-- [Framework mock exports](testing-api.md)
-- [Add a mock for a custom module](testing-extending.md)
-- [Application module testing](../../app/docs/testing.md)
-- [HTTP testing](../../modules/http/docs/testing.md)
-- [Migrate an existing app to Fusion Vitest](../../vitest-plugin/react-app/docs/migrating-an-existing-app.md)

package/docs/testing-design.md

@@ -1,63 +0,0 @@
-# Design
-
-Why this entry point exists, what it substitutes, and the rules that keep it from growing into a mocking library.
-
-## Why this exists
-
-Fusion Framework cannot start without authenticating a user and resolving services from a registry. Both reach outside the process, so an application test either has to supply real credentials or hand-build a replacement for every built-in module.
-
-This entry point removes that work. It runs the **real** configure → initialize pipeline with the **real** built-in modules, and substitutes only the boundaries that leave the process.
-
-That distinction matters: module wiring, configuration validation and lifecycle hooks behave exactly as they do in production, so a test still catches wiring mistakes.
-
-## How mocks are organised
-
-> [!IMPORTANT]
-> This entry point contains **no mock logic**. Every module owns and exports its own test double from a `./mock` entry point. This entry point only composes the built-in set.
-
-```
-@equinor/fusion-framework-module-msal/mock               -> enableMsalMock
-@equinor/fusion-framework-module-service-discovery/mock  -> mockServiceDiscovery
-@equinor/fusion-framework/mock                           -> composes the above
-```
-
-Three consequences follow, and they are the reason for the split:
-
-- **Mocks cannot drift.** A test double lives beside the implementation it stands in for, so a change to the real interface breaks it in the same package, in the same build.
-- **Mocks version with their module.** Installing msal `v10` gets msal `v10`'s mock. There is no version matrix to reconcile.
-- **Application modules work the same way.** A team's own module exposes its own mock entry point and composes without this entry point knowing it exists.
-
-Adding mock support to another Fusion module means adding a `src/mock/` folder to that module — not editing this entry point.
-
-## What is actually substituted
-
-> [!IMPORTANT]
-> Only the **client** — the object that performs network I/O — is replaced. Providers, configurators, schema validation and module `initialize` are all real.
-
-For authentication this means `MsalProvider` itself runs. A test therefore observes real provider behaviour, including decisions the provider makes on the caller's behalf:
-
-```typescript
-const fusion = await mockFramework((configurator) => {
-  configurator.msal.setClientConfig({ auth: { clientId: 'my-app', tenantId: 'my-tenant' } });
-});
-
-const token = await fusion.modules.auth.acquireAccessToken();
-// scope is 'my-app/.default' — resolved by the real provider, not by the test double
-```
-
-A double that replaced the provider would have skipped that logic and quietly reported whatever it was told to.
-
-## Determinism
-
-Tokens and resolved services are identical across runs and across machines. `createMockToken` uses a fixed issue time, so a token can be compared or snapshotted directly.
-
-## Test-runner support
-
-The package has **no test-runner dependency**. It builds a real framework instance and returns it; assertions are the caller's concern. It works under Vitest today and would work unchanged under another runner.
-
-`vitest` appears only in `devDependencies`, for this entry point's own tests.
-
-> [!IMPORTANT]
-> This is deliberate, and it is why there is **no Fusion mocking API**. The framework's job is making the runtime *substitutable* — a real configurator that validates, an I/O-boundary client that needs no network or credentials, a registry you compose on the builder. Replacing an individual call is your runner's job, and it does it better: call assertions, argument matchers and reset semantics you already know.
->
-> Mock clients are therefore plain classes with ordinary methods. `vi.spyOn`, `bun:test`'s `spyOn` and Node's `t.mock.method` all work on them directly.

package/docs/testing-extending.md

@@ -1,102 +0,0 @@
-# Adding a mock for another module
-
-How to give a module a test double, whether it is one of ours or one of yours.
-
-## Mocking your own module
-
-An application module needs no support from this entry point. Ship a test double next to the module and apply it alongside the framework mocks.
-
-Two seams matter, and the second is the one teams miss:
-
-1. **A client seam** — `setClient`, the way `MsalConfigurator.setClient` and `setServiceDiscoveryClient` do — so the object performing I/O can be swapped.
-2. **Configuration on the builder** — so a test can adjust behaviour *without* constructing a client at all. `ServiceDiscoveryMockConfigurator.addService` is the reference: the configurator accumulates config, and the client is built from it when the module assembles its config.
-
-```typescript
-// @my-app/module-invoices/mock
-export const mockInvoices = (configurator, options = {}) => {
-  configurator.addConfig(
-    configureInvoices((builder) => {
-      builder.setClient({
-        getInvoice: async (id) => ({ id, total: options.total ?? 100 }),
-      });
-    }),
-  );
-};
-```
-
-```typescript
-// @my-app/module-invoices — the module's own type, exported for tests
-export type InvoiceModule = Module<'invoices', InvoiceClient, InvoiceConfigurator>;
-```
-
-Pass that descriptor to `mockFramework` as a type argument, and the module is typed on both the configurator and the returned instance:
-
-```typescript
-const fusion = await mockFramework<[InvoiceModule]>((configurator) => {
-  enableInvoicesMock(configurator, { total: 42 });
-});
-
-await fusion.modules.invoices.getInvoice('inv-1'); // typed, no cast
-```
-
-### Giving your module the same accessor as `.msal` and `.serviceDiscovery`
-
-`enableInvoicesMock(configurator, options)` is enough on its own — the configurator it builds is discarded once configuration runs, which is fine when a test only ever sets options up front. Reach for an accessor when a test needs the configurator itself, for example to assert against it after the fact.
-
-Subclass `FrameworkMockConfigurator` and use the protected `_pin`/`_getConfig` pair it exposes for exactly this — the same mechanism `.msal` and `.serviceDiscovery` are built from:
-
-```typescript
-class AppMockConfigurator extends FrameworkMockConfigurator<[InvoiceModule]> {
-  constructor() {
-    super();
-    this._pin(invoiceMockModule);
-  }
-
-  get invoices(): InvoiceMockConfigurator {
-    return this._getConfig('invoices');
-  }
-}
-```
-
-`_pin` replaces the module's own `configure` factory with one that always returns the same instance — pinning it before initialization runs is what lets a test reach `.invoices` synchronously and have it be the configurator the module is actually built from. `_getConfig` looks that instance up by name, throwing if nothing was pinned for it.
-
-## What is not covered yet
-
-`.services` and `.telemetry` are already reachable on `FrameworkMockConfigurator` — their `configure` factories take no `ref`, so they were safe to pin the same way `.msal` and `.serviceDiscovery` are. What is missing is a test double behind them: neither module has a `src/mock/` folder yet, so anything issuing an actual request through them still reaches the network. Adding one means creating that folder in **that module**, then pinning its mock configurator with `_pin` and exposing it with `_getConfig` on `FrameworkMockConfigurator`, replacing the real module descriptor pinned there today.
-
-`event` is not pinned at all, deliberately: its `configure` factory reads `ref` to wire event bubbling to a parent event provider when `FrameworkMockConfigurator` is hoisted inside a host framework. Pinning would call `configure()` with `ref` always `undefined`, silently breaking that bubbling — so it is left to build the normal way, from the module system's own configure phase, where `ref` is actually known.
-
-## `.http`
-
-`.http` is the real `HttpClientConfigurator` built from `@equinor/fusion-framework-module-http` — there is no separate mock client. Register a short-circuiting middleware through `addMiddleware` to answer requests without touching the network:
-
-```typescript
-configurator.http.configureClient('catalog', { baseUri: 'https://api.example.com' });
-configurator.http.addMiddleware(async (uri, init, next) =>
-  uri === 'https://api.example.com/items' ? Response.json([{ id: 1 }]) : next(uri, init),
-);
-
-const items = await fusion.modules.http.createClient('catalog').json('/items');
-```
-
-A middleware is `(uri, init, next) => Response | Promise<Response> | Observable<Response>` — return a `Response` to answer the request, or call and return `next(uri, init)` to fall through to whichever middleware (or the real network call) is registered next. Two ways to fill that seam:
-
-- **`addMiddleware`** — a hand-rolled middleware for a handful of routes, as above.
-- **`createOpenApiMockMiddleware`** (`@equinor/fusion-framework-module-http/mock`) — adapts an `@equinor/fusion-openapi-mock` instance (`createOpenApiMock(document)`), so a real `openapi.json`/`openapi.yaml` fakes every response with no handlers written at all until an edge case needs overriding.
-
-## `.context`
-
-`.context` is backed by `ContextMockConfigurator` (`@equinor/fusion-framework-module-context/mock`): context items live in an in-memory pool instead of a real context API, so a test needs no HTTP mock and no service-discovery mock to seed a known item.
-
-```typescript
-configurator.context.setCurrentContext({ id: 'my-ctx', type: { id: 'ProjectMaster' }, value: {} });
-
-fusion.modules.context.currentContext; // the seeded item, resolved on startup
-```
-
-Real `ContextProvider` behaviour — `validateContext`, `resolveContext`, parent-context propagation — still runs against the seeded data; only the data source is substituted. Two layers cover different needs:
-
-- **`setCurrentContext`/`setContexts`/`addContext`/`setRelatedContexts`** — a friendly, context-domain vocabulary for the common case: seed a known item, get it back.
-- **`setResolver`** — an escape hatch for a custom `resolveContext` strategy or a shape the friendly layer did not anticipate.
-
-Seeding a context item this way is one of two ways to fake context in a test — the other is mocking the context API's HTTP responses directly (with `.http`, optionally paired with `createOpenApiMockMiddleware`), which exercises the real `ContextModuleConfigurator`/services/HTTP pipeline instead of substituting it. Reach for `.context` to seed one known item with no transport involved; reach for `.http` when the test needs to cover that pipeline itself.

package/docs/testing.md

@@ -1,178 +0,0 @@
-# Usage
-
-Recipes for the situations a test normally runs into. Every one of them builds a real framework instance — only the boundaries that leave the process are substituted.
-
-`mockFramework` takes a single callback, which receives a [`FrameworkMockConfigurator`](#the-configurator). That configurator **is** a `FrameworkConfigurator`, so everything an application does at configure time works here unchanged.
-
-## Zero configuration
-
-```typescript
-import { mockFramework } from '@equinor/fusion-framework/mock';
-
-const fusion = await mockFramework();
-
-fusion.modules.auth.account?.name; // 'Test User'
-await fusion.modules.serviceDiscovery.resolveService('apps'); // resolves offline
-```
-
-Every module declared by `FrameworkConfigurator` is initialized: `event`, `auth`, `http`, `serviceDiscovery`, `context` and `telemetry`.
-
-## The configurator
-
-Modules whose boundary is mocked expose their mock configurator directly, so a test configures them without registering a callback:
-
-| Property | Type |
-| --- | --- |
-| `msal` | `MsalMockConfigurator` |
-| `serviceDiscovery` | `ServiceDiscoveryMockConfigurator` |
-| `http` | `IHttpClientConfigurator` (the real configurator — see [`.http`](testing-extending.md#http)) |
-| `context` | `ContextMockConfigurator` |
-| `telemetry` | `TelemetryMockConfigurator` |
-
-```typescript
-const fusion = await mockFramework((configurator) => {
-  configurator.msal.setAccount({ name: 'Ada Lovelace' });
-  configurator.serviceDiscovery.setBaseUri('http://localhost:6669');
-});
-```
-
-These are the real module configurators, so the real builder API, the real validation and the real provider are used.
-
-## Choosing the signed-in user
-
-```typescript
-const fusion = await mockFramework((configurator) => {
-  configurator.msal.setAccount({ name: 'Ada Lovelace', username: 'ada@equinor.com' });
-});
-
-const token = await fusion.modules.auth.acquireAccessToken({
-  request: { scopes: ['Files.Read'] },
-});
-```
-
-The token is a structurally valid JWT carrying the claims an application reads. It is unsigned by default and must never be accepted by anything but a test.
-
-`setAccount` records configuration only — the user is signed in on the client before the provider initializes. It takes an object, `null` when nobody is signed in, or an ordinary config-builder callback resolving either:
-
-```typescript
-configurator.msal.setAccount(null);
-configurator.msal.setAccount(async ({ hasModule }) => ({
-  name: hasModule('app') ? 'App User' : 'Portal User',
-}));
-```
-
-Because the user is in place before `MsalProvider.initialize()` runs, the provider's real start-up path acts on it — pair `signedOut` with `setRequiresAuth(true)` to watch the automatic login happen.
-
-The account replaces any previously declared account, and is signed in on whichever client the module authenticates through — the one it builds, one supplied through `setClient`, or the host's when the module is hoisted onto a host application's provider. When that client cannot represent a declared user, it throws rather than failing quietly.
-
-## Testing signed-out behaviour
-
-```typescript
-const fusion = await mockFramework((configurator) => {
-  configurator.msal.setAccount({ signedOut: true });
-});
-
-fusion.modules.auth.account; // null
-```
-
-Silent flows then resolve empty so the provider follows its unauthenticated path, while an explicit `login()` still succeeds — so a test can drive the sign-in journey, not only its end state.
-
-## Composing the service registry
-
-Nothing has to be constructed to add a service, or to move every service to a locally running mock server such as Mockoon or Prism — in which case the application makes real HTTP calls with nothing intercepting them.
-
-```typescript
-const fusion = await mockFramework((configurator) => {
-  configurator.serviceDiscovery.setBaseUri('http://localhost:6669');
-  configurator.serviceDiscovery.addService({ key: 'my-api' });
-  configurator.serviceDiscovery.removeService('bookmarks');
-});
-```
-
-To replace the baseline registry outright rather than compose onto it, use `setServices`:
-
-```typescript
-configurator.serviceDiscovery.setServices([{ key: 'apps', uri: 'http://localhost:3000' }]);
-```
-
-By default an undeclared service resolves to a synthesised entry rather than throwing, so a test does not fail merely because the application resolved something the test did not think to declare. Call `setResolveUnknownServices(false)` to assert the opposite.
-
-> [!WARNING]
-> Built-in modules resolve services **while the framework starts** — the context module resolves `context`, for example. Combining `setResolveUnknownServices(false)` with a `setServices` registry that omits them fails initialization rather than the assertion you were writing. Either keep synthesis on, or declare every service the framework itself needs.
-
-## Seeding context
-
-```typescript
-const fusion = await mockFramework((configurator) => {
-  configurator.context.setCurrentContext({ id: 'project-42', type: { id: 'ProjectMaster' }, value: {} });
-});
-
-fusion.modules.context.currentContext; // the seeded item
-```
-
-`configurator.context` is a `ContextMockConfigurator` — a small, context-domain vocabulary (`setCurrentContext`, `setContexts`, `addContext`, `setRelatedContexts`) covers seeding a known item with no HTTP mock and no service-discovery mock required. `setResolver` is the escape hatch for a custom resolution need the friendly methods do not cover. Real `ContextProvider` behaviour — `validateContext`, `resolveContext`, parent-context propagation — still runs against the seeded data in both.
-
-This is one of two ways to fake context data: seeding an item directly (above) substitutes only the data source, with no transport involved. Mocking the context API's HTTP responses instead, through `.http`, exercises the real `ContextModuleConfigurator`/services/HTTP pipeline — reach for that when the test needs to cover that pipeline itself, optionally paired with `createOpenApiMockMiddleware` for faker-generated data straight from context's OpenAPI spec.
-
-## Mocking an individual call
-
-That is your test runner's job, not this entry point's. Mock clients are plain classes with ordinary methods, so any runner can spy on them with its own tooling — including call assertions and its own reset semantics.
-
-```typescript
-vi.spyOn(fusion.modules.serviceDiscovery.client, 'resolveService').mockResolvedValue(service);
-
-afterEach(() => vi.restoreAllMocks());
-```
-
-The same holds for `bun:test`'s `spyOn` and Node's `t.mock.method`, which is why this entry point introduces no mocking API of its own.
-
-## Configuring the framework as an application does
-
-The configurator is a `FrameworkConfigurator`, so every `enableX` and `configureX` helper is available and behaves normally.
-
-```typescript
-const fusion = await mockFramework((configurator) => {
-  configurator.onConfigured(() => {
-    /* ... */
-  });
-});
-```
-
-Mocks are registered **before** the callback runs, so anything configured there wins — including replacing a mock with a different one.
-
-## Registering your own modules
-
-Pass your module descriptors as a type argument. They are then typed on both the configurator and the returned instance, so no cast is needed to reach them.
-
-```typescript
-const fusion = await mockFramework<[InvoiceModule]>((configurator) => {
-  enableInvoicesMock(configurator, { total: 42 });
-});
-
-await fusion.modules.invoices.getInvoice('inv-1'); // fully typed
-```
-
-`addModule` is available if it reads better at the call site; it is sugar for the same call.
-
-```typescript
-configurator.addModule((c) => enableInvoicesMock(c, { total: 42 }));
-```
-
-> [!NOTE]
-> Only modules that ship a mock configurator get a property such as `configurator.msal`. Everything else is registered exactly as it is in production — through its own `enableX` helper or `configurator.addConfig`. Module *instances* never exist at configure time; they are created by `initialize`.
-
-See [Adding a mock for another module](./testing-extending.md) for how to give your module a test double, and a property on the configurator.
-
-## Bringing your own configurator
-
-`FrameworkMockConfigurator` can be constructed directly and initialized with `init`, which is useful when a test needs to hold on to the configurator.
-
-```typescript
-import { init } from '@equinor/fusion-framework';
-import { FrameworkMockConfigurator } from '@equinor/fusion-framework/mock';
-
-const configurator = new FrameworkMockConfigurator();
-configurator.msal.setAccount({ name: 'Ada Lovelace' });
-
-const fusion = await init(configurator);
-```