External Bundle
3.5External Bundle lets you build a Lynx bundle once and load it from multiple Lynx apps at runtime. Use it when you want to share ReactLynx components or common business bundles across apps.
Compared with Chunk Splitting, External Bundle is for cross-application reuse, while Chunk Splitting is for splitting code inside one app.
This workflow has two parts:
- Use
@lynx-js/lynx-bundle-rslib-configto build the external bundle. - Use
@lynx-js/external-bundle-rsbuild-pluginto load it in the host app.
The responsibilities are equally simple:
- the library build emits the
.lynx.bundle - the host app declares where the bundle is loaded from and which section the runtime should request
Install
@lynx-js/react-umd is needed
@lynx-js/react-umd provides the ReactLynx runtime bundles required by the built-in reactlynx preset.
When you enable externalsPresets.reactlynx, the plugin resolves @lynx-js/react-umd/dev or @lynx-js/react-umd/prod based on NODE_ENV, emits react.lynx.bundle, and loads it through the current runtime public path.
For most projects, installing @lynx-js/react-umd and enabling the reactlynx preset is enough.
Build An External Bundle
For a ReactLynx component bundle, the recommended setup is:
externalsPresets.reactlynx maps the standard ReactLynx requests for you, so a ReactLynx component bundle can depend on the shared runtime directly.
Run the build with:
After a successful build, you will get an output directory like this:
Bundle CSS
3.7If you need to run CSS from the External Bundle, set engineVersion: '3.7' when building that bundle:
Pure JS / TS External Bundles do not need this.
Load It In The Host App
Use the same request key in the app:
This shorthand is equivalent to the following expanded config:
If your section names already match the request key, this is the smallest recommended setup.
Verify It Works
After the configuration above, use these signals to confirm that the External Bundle is wired up correctly:
- the host app successfully requests
comp-lib.lynx.bundleat runtime - when
externalsPresets.reactlynxis enabled, the runtime also loadsreact.lynx.bundleautomatically - components from the External Bundle render normally, without section mismatch or bundle loading failures
If it still does not run, check whether the request key, bundle path, and section names in externals are aligned.
Advanced: When To Set globalObject
In most projects, you can omit globalObject.
Set globalObject: 'globalThis' only when your app enables a shared globalThis across background-thread runtimes and you want later bundles to reuse externals that have already been loaded there.
Use it on both sides when needed:
Extend Presets
Use the same preset name on both sides so the bundle build and the host app stay aligned.
From The Library Side
On the external bundle build side, presets live in output.externalsPresets and output.externalsPresetDefinitions:
This side decides how imports are mapped to external globals when the bundle is built.
From The Lynx Page Side
On the host app side, presets live in pluginExternalBundle({ externalsPresets, externalsPresetDefinitions }):
This side decides where the bundle is loaded from and which section names the runtime should request.
Explicit externals still override mappings provided by presets. Use that when a single app needs a different bundle path or section name.
Advanced: When To Use The Object Form
Use the full object form when you need custom section names, custom exported library names, timeouts, or a dedicated local bundle directory.
The external-bundle example in lynx-examples uses that style:
Use this form when:
- one bundle contains multiple business modules
- section names do not match the request key
- bundles are built into
dist-external-bundle - you want per-bundle timeout or loading behavior
Example
The lynx-examples external-bundle example is available directly in the docs: