External Bundle
3.5External Bundle packages code into standalone modules that can be dynamically loaded across different Lynx applications to reduce bundle size. The usage process involves two steps:
@lynx-js/lynx-bundle-rslib-config- Used to build External Bundle@lynx-js/external-bundle-rsbuild-plugin- Used to load External Bundle in applications
Differences from Chunk Splitting:
- Thread Support: Chunk Splitting only supports background thread code splitting, while External Bundle supports both background thread and main thread
- Cross-Application Sharing: External Bundle can be shared across multiple Lynx applications to reduce duplicate code, while Chunk Splitting artifacts are only used within the current application
- Packaging Method: Chunk Splitting is automatically split during build and deployed together with the application; External Bundle requires separate building, which can be deployed with the application artifacts or uploaded to CDN or server for dynamic loading at runtime
- Use Cases: External Bundle is suitable for common libraries shared across applications (e.g.,
lodash-es,moment); Chunk Splitting is suitable for code splitting optimization within a single application
1. Building External Bundle
Installation
Basic Usage
Use defineExternalBundleRslibConfig() in rslib.config.ts to define the build configuration for External Bundle.
Example 1: Support Both Background Thread and Main Thread
Run the following command to build:
The output file is dist/lodash-es.lynx.bundle, with the file name prefix determined by the id configuration. You can upload .lynx.bundle files to a CDN or server.
Since Lynx background thread and main thread have different artifact formats, the current version builds artifacts separately for both threads. The dist/lodash-es.lynx.bundle artifact content looks like:
Future versions will support unified code artifacts to further reduce bundle size.
The 'lodash-es' and 'lodash-es__main-thread' in the artifacts above are called section path, which are identifiers for internal modules in .lynx.bundle. These section paths need to be configured through background.sectionPath and mainThread.sectionPath when loading external bundle. We will introduce this in the following sections.
Example 2: Background Thread Only
The dist/lodash-es.lynx.bundle artifact content looks like:
Example 3: Main Thread Only
The dist/lodash-es.lynx.bundle artifact content looks like:
Bundle Multiple Dependencies
Supports packaging multiple dependencies into the same external bundle to reduce the number of runtime requests and improve performance.
The dist/lodash.lynx.bundle artifact content looks like:
Referencing Other External Bundles
When an external bundle depends on other external bundles, you can declare these dependencies as external dependencies via output.externals to avoid duplicate packaging:
Before loading my-components at runtime, you must ensure that the @lynx-js/react external bundle has been loaded, otherwise it will cause runtime errors.
Custom Configuration
defineExternalBundleRslibConfig() automatically applies default configuration. To modify the default configuration, simply override it in the configuration object:
Viewing Bundle Intermediate Artifacts
.lynx.bundle is a compiled artifact and cannot be read directly. If you need to view the pre-compiled code, add the DEBUG=rspeedy environment variable:
This will output the following intermediate artifacts:
2. Loading External Bundle
Based on Webpack Externals implementation. When importing an external bundle, dependencies are not bundled into the main bundle but dynamically loaded from .lynx.bundle files.
Installation
Basic Usage
If your code uses lodash-es:
Use the pluginExternalBundle plugin in lynx.config.ts to configure lodash-es in externals, avoiding packaging it into the main bundle:
After configuration, lodash-es in your code will not be bundled into the main bundle but dynamically loaded from the specified URL at runtime.
Configuring Multiple External Bundles
You can configure multiple external bundles in externals:
Configuration Options
- url: External Bundle loading address (required)
- libraryName: Specify global variable name,
string/string[](optional) - background: Background thread configuration, including
sectionPath(optional) - mainThread: Main thread configuration, including
sectionPath(optional) - async: Whether to load asynchronously, defaults to
true(optional)
libraryName
Specifies which global variable to read the external bundle's module exports from. Usually no configuration is needed, as the plugin automatically infers based on the package's import name.
When external bundle is mounted to a nested object, use string[] to specify the access path:
Most of the time, you can just rely on automatic inference:
sectionPath
sectionPath is the path identifier for internal modules within the external bundle:
- background: Module path used by the background thread
- mainThread: Module path used by the main thread
sectionPath must exactly match the actual output section name when building the external bundle, otherwise runtime errors will occur due to the missing corresponding module.
Taking Building External Bundle - Example 1 as an example, the corresponding sectionPath configuration is as follows:
If your external bundle only supports a specific thread (refer to Building External Bundle - Example 2 and Building External Bundle - Example 3), you only need to configure the sectionPath for the corresponding thread: