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],
};
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']}],
}
};
Note: If an exclusion matches an unexposed dependency, the exclusion will be ignored. Unexposed dependencies will always be rolled up.
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 be useful when you want to share a module across application component graphs. Use in conjunction with preloadModules
or externals
configuration properties.