Externals | webpack

The externals configuration option provides a way of excluding dependencies from the output bundles. Instead, the created bundle relies on that dependency to be present in the consumer's (any end-user application) environment. This feature is typically most useful to library developers, however there are a variety of applications for it.
string RegExp object ExternalsFn (string | RegExp | object | ExternalsFn)[]
Prevent bundling of certain imported packages and instead retrieve these external dependencies at runtime.
For example, to include jQuery from a CDN instead of bundling it:
This leaves any dependent modules unchanged, i.e. the code shown below will still work:
The property name jquery specified under externals in the above webpack.config.js indicates that the module jquery in import $ from 'jquery' should be excluded from bundling. In order to replace this module, the value jQuery will be used to retrieve a global jQuery variable, as the default external library type is var when neither output.library.type nor output.module is set, see externalsType.
While we showed an example consuming external global variable above, the external can actually be available in any of these forms: global variable, CommonJS, AMD, ES2015 Module, see more in externalsType.
Depending on the externalsType, this could be the name of the global variable (see 'global', 'this', 'var', 'window') or the name of the module (see amd, commonjs, module, umd).
You can also use the shortcut syntax if you're defining only 1 external:
You can specify the external library type to the external with the ${externalsType} ${libraryName} syntax. It will override the default external library type specified in the externalsType option.
For example, if the external library is a CommonJS module, you can specify
subtract: ['./math', 'subtract'] allows you select part of a module, where ./math is the module and your bundle only requires the subset under the subtract variable.
When the externalsType is commonjs, this example would translate to require('./math').subtract; while when the externalsType is window, this example would translate to window["./math"]["subtract"];
Similar to the string syntax, you can specify the external library type with the ${externalsType} ${libraryName} syntax, in the first item of the array, for example:
An object with { root, amd, commonjs, ... } maps externals types to the external's target for each type. A umd library reads the root, amd, commonjs and commonjs2 entries, an amd or system library reads amd, and for any other externals type webpack uses the entry matching the effective type.
Since webpack 5.109.0, an object external with no entry for the used externals type emits a build error instead of silently resolving to undefined at runtime.
This syntax is used to describe all the possible ways that an external library can be made available. lodash here is available as lodash under AMD and CommonJS module systems but available as _ in a global variable form. subtract here is available via the property subtract under the global math object (e.g. window['math']['subtract']).
Non-ESM externals (commonjs, amd, umd, ...) are dynamic modules: importing their default from a strict ES module (a package with "type": "module") yields the whole exports object, while a non-strict importer unboxes it through the runtime __esModule check. The optional interop hint on an object external pins this behavior independent of the importer, mirroring Rollup's output.interop:
An external value can also be given as an object carrying the target under external plus options describing how webpack should treat it:
webpack cannot analyze an external, so it has to assume that importing one does something observable and keeps the import even when nothing reads its exports. sideEffects: false states the opposite, and lets webpack drop the external entirely when none of its exports are used. This matters most for a large external imported by a barrel file, where the request would otherwise survive into every chunk that touches the barrel.
Only set it when the package really is free of side effects. Getting it wrong removes an import that the runtime was relying on for its effect, and the failure shows up at runtime rather than at build time.
An ExternalsFn comes in two forms:
It might be useful to define your own function to control the behavior of what you want to externalize from webpack. webpack-node-externals, for example, excludes all modules from the node_modules directory and provides options to allowlist packages.
Here're arguments the function can receive:
The callback function takes three arguments:
As an example, to externalize all imports where the import path matches a regular expression you could do the following:
Other examples using different module formats:
Every dependency that matches the given regular expression will be excluded from the output bundles.
In this case, any dependency named jQuery, capitalized or not, or $ would be externalized.
Sometimes you may want to use a combination of the above syntaxes. This can be done in the following manner:
Default type will be used if you specify externals without a type e.g. externals: { react: 'react' } instead of externals: { react: 'commonjs-module react' }.
For more information on how to use this configuration, please refer to the article on how to author a library.
Record<string, ExternalItem> (layer: string | null) => ExternalItem
Specify externals by layer.
Specify the default type of externals. It defaults to output.library.type when that is a valid externals type, otherwise to 'module-import' when output.module is enabled, and to 'var' otherwise. amd, umd, system and jsonp externals depend on the output.libraryTarget being set to the same value e.g. you can only consume amd externals within an amd library.
Specify the default type of externals as 'amd-async'. Like 'amd', the external is resolved through an AMD loader, but it is loaded at runtime via the