Module Methods | webpack

This section covers all methods available in code compiled with webpack. When using webpack to bundle your application, you can pick from a variety of module syntax styles including ES6, CommonJS, and AMD.
While webpack supports multiple module syntaxes, we recommend following a single syntax for consistency and to avoid odd behaviors/bugs. Actually webpack would enforce the recommendation for .mjs files, .cjs files or .js files when their nearest parent package.json file contains a "type" field with a value of either "module" or "commonjs". Please pay attention to these enforcements before you read on:
Version 2 of webpack supports ES6 module syntax natively, meaning you can use import and export without a tool like babel to handle this for you. Keep in mind that you will still probably need babel for other ES6+ features. The following methods are supported by webpack:
Statically import the exports of another module.
The keyword here is statically. A normal import statement cannot be used dynamically within other logic or contain variables. See the spec for more information and import() below for dynamic usage.
You can also import Data URI:
Export anything as a default or named export.
(path: string) => Promise<any>
Dynamically load modules. Calls to import() are treated as split points, meaning the requested module and its children are split out into a separate chunk.
The ES2015 Loader spec defines import() as method to load ES2015 modules dynamically on runtime.
This feature relies on Promise internally. If you use import() with older browsers, remember to shim Promise using a polyfill such as es6-promise or promise-polyfill.
It is not possible to use a fully dynamic import statement, such as import(foo). Because foo could potentially be any path to any file in your system or project.
The import() must contain at least some information about where the module is located. Bundling can be limited to a specific directory or set of files so that when you are using a dynamic expression - every module that could potentially be requested on an import() call is included. For example, import(`./locale/${language}.json`) will only bundle all .json files in the ./locale directory and subdirectories into the new chunk and exclude files with other file extensions. At run time, when the variable language has been computed, any file like english.json or german.json will be available for consumption.
Using the webpackInclude and webpackExclude options allows you to add regex patterns that reduce the number of files that webpack will bundle for this import.
A fully dynamic import(foo) is not an error — webpack still creates a context module for it, but an empty one. It reports Critical dependency: the request of a dependency is an expression at build time, bundles nothing for that call, and the returned promise rejects at runtime. Nothing is included because the parser can't tell which files could be requested, and including every file the expression might resolve to is almost never what you want.
If it is what you want, the module context options let you opt in — exprContextRequest is the directory to look in, exprContextRegExp selects the files inside it, exprContextRecursive decides whether subdirectories are included, and exprContextCritical controls the warning:
Every module matched this way ends up in the bundle, so this can grow the output dramatically. Prefer keeping a static prefix in the request, as in the example above. The equivalent options for an unanalyzable require(expr) are named unknownContextRequest, unknownContextRegExp, unknownContextRecursive and unknownContextCritical.
By adding comments to the import, we can do things such as name our chunk or select different modes. For a full list of these magic comments see the code below followed by an explanation of what these comments do.
Single line comments (//) are also supported. JSDoc comments (/** */) are not.
Disables dynamic import parsing when set to true.
When using import.meta.url, it does not remain as-is; instead, it gets replaced based on the baseURI. For modules, it is replaced with new URL("./", import.meta.url), and for other cases, it defaults to document.baseURI. This ensures that relative URLs work correctly, aligning with the base URL context.
Note that setting webpackIgnore to true opts out of code splitting.
The webpackIgnore comment can control whether webpack processes a specific import or URL reference. It works in certain cases out of the box but doesn’t support all cases by default due to performance reasons.
We support webpackIgnore in the following cases:
The same comment works in CSS handled by webpack's built-in CSS support: put /* webpackIgnore: true */ before an @import or a url() to leave it as written.
When experiments.html is enabled, webpackIgnore can be placed as an HTML comment immediately before a tag to skip URL resolution for that tag's src, href, srcset, and similar attributes. The tag is left untouched in the emitted HTML.
The magic-comment value is parsed with the same context used by the JS and CSS parsers; non-boolean values emit an UnsupportedFeatureWarning.
A name for the new chunk. Since webpack 2.6.0, the placeholders [index] and [request] are supported within the given string to an incremented number or the actual resolved filename respectively. Adding this comment will cause our separate chunk to be named [my-chunk-name].js instead of [id].js.
Set fetchPriority for specific dynamic imports. It's also possible to set a global default value for all dynamic imports by using the module.parser.javascript.dynamicImportFetchPriority option.
Since webpack 2.6.0, different modes for resolving dynamic imports can be specified. The following options are supported:
Tells the browser that the resource is probably needed for some navigation in the future. Check out the guide for more information on how webpackPrefetch works.
Tells the browser that the resource might be needed during the current navig