@equinor/fusion-framework-module-app

中文文档
8.3.0发布于 2026/11/12ISCTypeScriptES Module近 30 天下载 1.2万
原始使用文档
文档目录13 节
  1. When to Use
  2. Quick Start
  3. Core Concepts
  4. AppModuleProvider
  5. App
  6. AppClient
  7. AppConfig
  8. AppConfigurator
  9. Events
  10. Error Handling
  11. Operational telemetry
  12. Testing
  13. Main Exports

@equinor/fusion-framework-module-app

Framework module for loading, configuring, and managing Fusion applications at runtime.

Primarily used by portal hosts and other framework initiators that need to discover, load, and switch between applications dynamically. The module handles manifest fetching, build resolution, configuration loading, per-user app settings, and script import of application bundles.

When to Use

  • You are building a portal or shell that hosts multiple Fusion applications.
  • You need to fetch application manifests and configurations from the Fusion app service.
  • You need to dynamically import an application's JavaScript bundle at runtime.
  • You need to read or write per-user application settings.

[!NOTE] By design this module only allows one active application at a time (currentApp). If you need multiple concurrent app instances, use the Widgets module instead.

Quick Start

Enable the module in your framework configurator:

import { enableAppModule } from '@equinor/fusion-framework-module-app';

export const configure = async (configurator: FrameworkConfigurator) => {
  enableAppModule(configurator);
};

Once enabled, the AppModuleProvider is available on the framework instance:

const appProvider = framework.modules.app;

// Set the current application by key
appProvider.setCurrentApp('my-app');

// React to current app changes
appProvider.current$.subscribe((app) => {
  if (app) {
    console.log('Current app:', app.appKey);
  }
});

Core Concepts

AppModuleProvider

The main runtime entry point. Provides methods to:

  • Fetch manifests – getAppManifest(appKey) and getAppManifests() return observable streams of AppManifest objects.
  • Fetch configuration – getAppConfig(appKey) returns the app's environment and endpoint configuration.
  • Manage settings – getAppSettings(appKey) and updateAppSettings(appKey, settings) read and write per-user settings.
  • Set/clear current app – setCurrentApp(appKey) creates an App instance and emits it on current$. clearCurrentApp() disposes the current app.

App

Represents a single loaded application. Manages internal state for the manifest, config, settings, and imported script module via a reactive state machine (FlowSubject). Key observables:

ObservableEmits
manifest$AppManifest when resolved
config$AppConfig when resolved
settings$AppSettings (fetched on subscribe)
modules$Imported AppScriptModule
instance$Initialized AppModulesInstance
status$Set of in-progress action types

Call app.initialize() to load manifest, config, and script in parallel and receive them as a combined observable.

AppClient

Low-level HTTP client that communicates with the Fusion app service API. Handles caching (via Query), response parsing (via Zod schemas), and error mapping to typed error classes (AppManifestError, AppConfigError, AppBuildError, AppSettingsError).

AppConfig

Immutable, deeply frozen configuration object with environment (arbitrary key-value data) and endpoints (named URLs with OAuth scopes). Use config.getEndpoint('api') to retrieve a specific endpoint.

AppConfigurator

Configuration builder used during module initialization. Allows overriding the default HTTP client and asset URI:

enableAppModule(configurator, (builder) => {
  builder.setClient(async (args) => {
    const http = await args.requireInstance('http');
    return new AppClient(http.createClient('my-custom-apps'));
  });
  builder.setAssetUri('/custom-proxy');
});

Events

When the EventModule is available, the app module dispatches lifecycle events on manifest, config, settings, and script loading. Key events include:

  • onCurrentAppChanged – fired when setCurrentApp or clearCurrentApp is called
  • onAppManifestLoad / onAppManifestLoaded / onAppManifestFailure
  • onAppConfigLoad / onAppConfigLoaded / onAppConfigFailure
  • onAppSettingsLoad / onAppSettingsLoaded / onAppSettingsFailure
  • onAppScriptLoad / onAppScriptLoaded / onAppScriptFailure
  • onAppInitialize / onAppInitialized / onAppInitializeFailure
  • onAppDispose

Error Handling

All API requests map HTTP status codes to typed error classes:

Error ClassWhen Thrown
AppManifestErrorManifest fetch fails (404, 401, 410)
AppConfigErrorConfig fetch fails
AppBuildErrorBuild metadata fetch fails
AppSettingsErrorSettings fetch or update fails
AppScriptModuleErrorScript import fails

Each error includes a type property ('not_found', 'unauthorized', 'deleted', or 'unknown') for programmatic handling.

Operational telemetry

The provider implements TelemetryConnectable and obtains its shared handle through telemetry.scope('app'), with a lazy factory fallback for older custom providers. Each app owns a child scope; stage observers stay local, while timing, safe identity and disposal use the shared telemetry implementation.

When the host registers telemetry, every app reports one fusion.app.<stage>.duration outcome per attempted stage: load-manifest, load-config, load-settings, update-settings, import, load, and unload when the app is replaced or cleared. load is the outcome of each initialize() subscription: its result, its error, or cancelled when the caller unsubscribes first. Outcomes are success, failure (plus one sanitized .failure exception; stage failures carry a static reason such as not-found) or cancelled (reason superseded, unloaded, or disposed when the app module is disposed). A teardown that throws records a failed unload. Records carry only the validated appKey and appVersion; manifests, configuration, settings, URLs and error messages are never exported. A replaced app stops load reporting immediately, even while asynchronous module teardown is pending; its separately owned unload measurement finishes when teardown settles. Queued stage outcomes stay correlated with the request that produced them, not a newer request for the same stage.

Telemetry is connected after initialization and is never awaited, so loading results, errors and cancellation are unchanged. Exclude these records with a telemetry adapter or relay filter on diagnostic.module === 'app'. See Operational telemetry.

Testing

Import from @equinor/fusion-framework-module-app/mock to serve one app's manifest and config locally instead of contacting the app service. The real AppClient still backs every other request — other app keys, tagged requests, builds, settings — so pointing setClient at a different http client or service discovery registry keeps working unchanged.

import { MockAppClient } from '@equinor/fusion-framework-module-app/mock';

enableAppModule(configurator, (builder) => {
  builder.setClient(async ({ requireInstance }) => {
    const http = await requireInstance('http');
    return new MockAppClient(http.createClient('apps'), manifest, config);
  });
});

getAppManifest only resolves locally for manifest.appKey with no tag at all. getAppConfig resolves for manifest.appKey when tag is either absent or equal to the manifest's own build.version — the same tag App requests when loading config for the manifest it already resolved. Any other app key, tag, or the wrong request falls through to the real client.

[!NOTE] @equinor/fusion-framework-app/mock's mockAppModules builds on top of this class and is usually the simpler entry point for testing an application — see its Testing guide.

Main Exports

ExportDescription
enableAppModuleRegisters the module with a framework configurator
AppModuleProviderRuntime provider with app lifecycle methods
AppClientLow-level HTTP client for the app service
AppConfiguratorConfiguration builder for module setup
AppConfigImmutable app configuration (env + endpoints)
App / IAppApplication instance with reactive state
AppModuleModule definition for the framework
MockAppClientTest double serving one app's manifest and config locally (/mock)

版本与发布记录

@equinor/fusion-framework-module-app 共发布 249 个版本,首次发布于 2022/01/14;过去 12 个月发布了 29 个版本。

版本发布日期距今
8.3.0latest2026/11/121 天前
8.3.0-next.1next2026/11/112 天前
8.3.0-next.02026/10/2816 天前
8.2.22026/10/1727 天前
8.2.2-trusted-publishing-20261015-9dfe7602cd2a49a8a9df00d62c26e7304a82a85atrusted-publishing-202610152026/10/1629 天前
8.2.12026/10/121 个月前

其他发布通道:apploader → 6.1.14-apploader-be21a6b60eb13eee8bf869e75002d8634e9c50a9,cli-search-index → 7.1.1-cli-search-index.0,msal-v5 → 7.2.3-msal-v5.0,trusted-publishing-20261015 → 8.2.2-trusted-publishing-20261015-9dfe7602cd2a49a8a9df00d62c26e7304a82a85a,next → 8.3.0-next.1。

关于 @equinor/fusion-framework-module-app 的常见问题

如何安装 @equinor/fusion-framework-module-app?

在项目目录运行 npm install @equinor/fusion-framework-module-app,或使用 pnpm add / yarn add / bun add。

@equinor/fusion-framework-module-app 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@equinor/fusion-framework-module-app 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@equinor/fusion-framework-module-app 可以商用吗?

@equinor/fusion-framework-module-app 使用 ISC 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@equinor/fusion-framework-module-app 的下载量有多少?

根据 npm 官方下载统计,@equinor/fusion-framework-module-app 在 2026/10/14 – 2026/11/12 这 30 天内被下载 12,176 次,日均约 406 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@equinor/fusion-framework-module-app 还在维护吗?

最新版本 8.3.0 发布于 2026/11/12(1 天前);至今共发布 249 个版本,其中过去 12 个月发布了 29 个;首次发布于 2022/01/14。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。