@webruntime/api v1.61.4

Lightning Web Runtime :: Core API

The Lightning Web Runtime server is a pluggable application server. The Core API package provides the base definitions which describe the Runtime's configuration.

Configuration

Application configuration and customization is done primarily in webruntime-app.config.js. Customization includes:

• what services the application server will use
• the page application container to use, which governs the pages rendered by the application
• how the module bundler (rollup.js) choses which components to bundle together during compilation
• how components are bundled and provided to the client

Services Configuration

Addressable Services configuration describes the HTTP addressable services supported by your LWR application.

const { ComponentService, ImportMapService, AppBootstrapService } = require('@webruntime/services');

module.exports = {
    // Addressable Services
    services: [ComponentService, ImportMapService, AppBootstrapService],
};

See Addressable Services API

Application Configuration

Application configuration defines your application component(s) (an application component is simply a LWC that is the root/parent component of a page), and the page(s) which contain them.

    // Application Configuration
    app: {
        defaultComponent: 'my/app',
        defaultTemplate: 'src/index.html',
    },

See Application API

Component Rollup

Configuration of how components are bundled together during compilation is described by the CompilerConfig.inlineConfig configuration property.

When a component is compiled, dependent components can be rolled up in to the component's source. This produces a compiled component with both the root and its dependencies inlined in to the resulting generated code.

The inlineConfig property allows you to configure which components are rolled up in to the generated source.

By default, the compiler will attempt to rollup all components available to the compiler. This includes components in the moduleDir as well as components provided via package.json dependencies.

As a result, the inlineConfig directive is primarily an exclusion policy.

For example the following configuration, will exclude the shared/library component from being woven in to the generated code for the my/app component. This enables re-use of the shared/library component by others via Component Bundling or externals.

module.exports = {
    // Component Bundling Configuration
    compilerConfig {
        inlineConfig: [{ descriptor: 'my/app', exclude:['shared/library']}],
    }
};

Component Bundling

LWR compiles all your application code into manageable code "bundles". This is meant to ensure the application doesn't try to load unnecessary code, while also ensuring that code is available when the application needs it. When LWR creates these bundles, a decision has to be made on how large each bundle should be. The act of drawing that line at a certain boundary is usually referred to as code-splitting. LWR gives you control over the code splitting strategy.

For example, the following configuration directs the runtime to split the application in two ways --

• bundle all available dependencies of the root component -- my/app
• bundle all available dependencies for each page component -- pages/*

The bundle will not include dependendies, which are either preloaded using the preloadModules or consider external to the runtime container by the externals configuration property.

module.exports = {
    // Component Bundling Configuration
    bundle: ['my/app', 'pages/*'],
};

Note: In the case of component bundling the components are still individually registered in to the client component module registry, but are grouped together in to bundled response payload.

Bundling Exclusions

It is also possible to exclude components from a bundling request using the exclude property in the Bundle Config Entry.

module.exports = {
    // Component Bundling Configuration
    bundle: [{ descriptor: 'my/app', exclude: ['shared/library'] }, 'pages/*'],
};

This type of configuration can useful when you want to share a module across application component graphs. Use in conjunction with preloadModules or externals configuration properties.