Package exports | webpack

The exports field in the package.json of a package allows to declare which module should be used when using module requests like import "package" or import "package/sub/path". It replaces the default implementation that returns main field resp. index.js files for "package" and the file system lookup for "package/sub/path".
When the exports field is specified, only these module requests are available. Any other requests will lead to a ModuleNotFound Error.
In general the exports field should contain an object where each properties specifies a sub path of the module request. For the examples above the following properties could be used: "." for import "package" and "./sub/path" for import "package/sub/path". Properties ending with a / will forward a request with this prefix to the old file system lookup algorithm. For properties ending with *, * may take any value and any * in the property value is replaced with the taken value.
Instead of providing a single result, the package author may provide a list of results. In such a scenario this list is tried in order and the first valid result will be used.
Note: Only the first valid result will be used, not all valid results.
Here package/things/apple might be found in .../package/good-things/apple or in .../package/bad-things/apple.
As of version 5.94.0, webpack's behavior has been updated to align with Node's behavior. It now selects the first valid path without attempting further resolutions and throws an error if the path cannot be resolved.
For example, given the following configuration:
Webpack 5.94.0+ will now throw an error since non-existent.js is not found while the previous behavior would have resolved to existent.js.
Instead of providing results directly in the exports field, the package author may let the module system choose one based on conditions about the environment.
In this case an object mapping conditions to results should be used. Conditions are tried in object order. Once a condition matches, its target is used; if that target is null or cannot be resolved, resolution fails rather than trying later conditions. Conditions might be nested to create a logical AND. The last condition in the object might be the special "default" condition, which is always matched.
This translates to something like:
The available conditions vary depending on the module system and tool used.
When only a single entry (".") into the package should be supported the { ".": ... } object nesting can be omitted:
In an object where each key is a condition, order of properties is significant. Conditions are handled in the order they are specified.
Example: { "red": "./stop.js", "green": "./drive.js" } != { "green": "./drive.js", "red": "./stop.js" } (when both red and green conditions are set, first property will be used)
In an object where each key is a subpath, order of properties (subpaths) is not significant. More specific paths are preferred over less specific ones.
Example: { "./a/": "./x/", "./a/b/": "./y/", "./a/b/c": "./z" } == { "./a/b/c": "./z", "./a/b/": "./y/", "./a/": "./x/" } (order will always be: ./a/b/c > ./a/b/ > ./a/)
exports field is preferred over other package entry fields like main, module, browser or custom ones.
(1) Removed in Node.js 17. Use * instead.
(2) "./" is intentionally ignored as key.
(3) The property value is ignored and property key is used as target. Effectively only allowing mappings with key and value are identical.
(4) The syntax is supported, but always the first entry is used, which makes it unusable for any practical use case.
(5) Fallback to alternative sibling parent conditions is handling incorrectly.
(6) For the require condition object order is handled incorrectly. This is intentionally as wmr doesn't differ between referencing syntax.
(7) When using "exports": "./file.js" abbreviation, any request e. g. package/not-existing will resolve to that. When not using the abbreviation, direct file access e. g. package/file.js will not lead to an error.
One of these conditions is set depending on the syntax used to reference the module:
These conditions might also be set additionally:
(1) import and require are both set independent of referencing syntax. require has always lower priority.
The following syntax will set the import condition:
The following syntax will set the require condition:
The following syntax will set the style condition:
The following syntax will set the asset condition:
The following syntax will set the script condition:
script should only be set when no module system is supported. When the script is preprocessed by a system supporting CommonJs it should set require instead.
This condition should be used when looking for a javascript file that can be injected as script tag in a HTML page without additional preprocessing.
The following conditions are set for various optimizations:
Note: Since production and development is not supported by everyone, no assumption should be made when none of these is set.
The following conditions are set depending on the target environment:
(1) electron, worker and worklet comes combined with either node or browser, depending on the context.