These options change how modules are resolved. webpack provides reasonable defaults, but it is possible to change the resolving in detail. Have a look at Module Resolution for more explanation of how the resolver works.
resolve
object
Configure how modules are resolved. For example, when calling import 'lodash'
in ES2015, the resolve
options can change where webpack goes to look for 'lodash'
(see modules
).
webpack.config.js
module.exports = {
//...
resolve: {
// configuration options
},
};
resolve.alias
object
Create aliases to import
or require
certain modules more easily. For example, to alias a bunch of commonly used src/
folders:
webpack.config.js
const path = require('path');
module.exports = {
//...
resolve: {
alias: {
Utilities: path.resolve(__dirname, 'src/utilities/'),
Templates: path.resolve(__dirname, 'src/templates/'),
},
},
};
Now, instead of using relative paths when importing like so:
import Utility from '../../utilities/utility';
you can use the alias:
import Utility from 'Utilities/utility';
A trailing $
can also be added to the given object's keys to signify an exact match:
webpack.config.js
const path = require('path');
module.exports = {
//...
resolve: {
alias: {
xyz$: path.resolve(__dirname, 'path/to/file.js'),
},
},
};
which would yield these results:
import Test1 from 'xyz'; // Exact match, so path/to/file.js is resolved and imported
import Test2 from 'xyz/file.js'; // Not an exact match, normal resolution takes place
The following table explains other cases:
alias: | import 'xyz' | import 'xyz/file.js' |
---|---|---|
{} | /abc/node_modules/xyz/index.js | /abc/node_modules/xyz/file.js |
{ xyz: '/abc/path/to/file.js' } | /abc/path/to/file.js | error |
{ xyz$: '/abc/path/to/file.js' } | /abc/path/to/file.js | /abc/node_modules/xyz/file.js |
{ xyz: './dir/file.js' } | /abc/dir/file.js | error |
{ xyz$: './dir/file.js' } | /abc/dir/file.js | /abc/node_modules/xyz/file.js |
{ xyz: '/some/dir' } | /some/dir/index.js | /some/dir/file.js |
{ xyz$: '/some/dir' } | /some/dir/index.js | /abc/node_modules/xyz/file.js |
{ xyz: './dir' } | /abc/dir/index.js | /abc/dir/file.js |
{ xyz: 'modu' } | /abc/node_modules/modu/index.js | /abc/node_modules/modu/file.js |
{ xyz$: 'modu' } | /abc/node_modules/modu/index.js | /abc/node_modules/xyz/file.js |
{ xyz: 'modu/some/file.js' } | /abc/node_modules/modu/some/file.js | error |
{ xyz: 'modu/dir' } | /abc/node_modules/modu/dir/index.js | /abc/node_modules/modu/dir/file.js |
{ xyz$: 'modu/dir' } | /abc/node_modules/modu/dir/index.js | /abc/node_modules/xyz/file.js |
index.js
may resolve to another file if defined in the package.json
.
/abc/node_modules
may resolve in /node_modules
too.
module.exports = {
//...
resolve: {
alias: {
_: [
path.resolve(__dirname, 'src/utilities/'),
path.resolve(__dirname, 'src/templates/'),
],
},
},
};
Setting resolve.alias
to false
will tell webpack to ignore a module.
module.exports = {
//...
resolve: {
alias: {
'ignored-module': false,
'./ignored-module': false,
},
},
};
resolve.aliasFields
[string]: ['browser']
Specify a field, such as browser
, to be parsed according to this specification.
webpack.config.js
module.exports = {
//...
resolve: {
aliasFields: ['browser'],
},
};
resolve.cacheWithContext
boolean
(since webpack 3.1.0)
If unsafe cache is enabled, includes request.context
in the cache key. This option is taken into account by the enhanced-resolve
module. Since webpack 3.1.0 context in resolve caching is ignored when resolve or resolveLoader plugins are provided. This addresses a performance regression.
string[]
Condition names for exports
field which defines entry points of a package.
webpack.config.js
module.exports = {
//...
resolve: {
conditionNames: ['require', 'node'],
},
};
resolve.descriptionFiles
[string] = ['package.json']
The JSON files to use for descriptions.
webpack.config.js
module.exports = {
//...
resolve: {
descriptionFiles: ['package.json'],
},
};
resolve.enforceExtension
boolean = false
If true
, it will not allow extension-less files. So by default require('./foo')
works if ./foo
has a .js
extension, but with this enabled only require('./foo.js')
will work.
webpack.config.js
module.exports = {
//...
resolve: {
enforceExtension: false,
},
};
resolve.enforceModuleExtension
boolean = false
Tells webpack whether to require to use an extension for modules (e.g. loaders).
webpack.config.js
module.exports = {
//...
resolve: {
enforceModuleExtension: false,
},
};
[string] = ['.js', '.json', '.wasm']
Attempt to resolve these extensions in order. If multiple files share the same name but have different extensions, webpack will resolve the one with the extension listed first in the array and skip the rest.
webpack.config.js
module.exports = {
//...
resolve: {
extensions: ['.js', '.json', '.wasm'],
},
};
which is what enables users to leave off the extension when importing:
import File from '../path/to/file';
Note that using resolve.extensions
like above will override the default array, meaning that webpack will no longer try to resolve modules using the default extensions. However you can use '...'
to access the default extensions:
module.exports = {
//...
resolve: {
extensions: ['.ts', '...'],
},
};
Redirect module requests when normal resolving fails.
webpack.config.js
module.exports = {
//...
resolve: {
fallback: {
abc: false, // do not include a polyfill for abc
xyz: path.resolve(__dirname, 'path/to/file.js'), // include a polyfill for xyz
},
},
};
Webpack 5 no longer polyfills Node.js core modules automatically which means if you use them in your code running in browsers or alike, you will have to install compatible modules from npm and include them yourself. Here is a list of polyfills webpack has used before webpack 5:
module.exports = {
//...
resolve: {
fallback: {
assert: require.resolve('assert'),
buffer: require.resolve('buffer'),
console: require.resolve('console-browserify'),
constants: require.resolve('constants-browserify'),
crypto: require.resolve('crypto-browserify'),
domain: require.resolve('domain-browser'),
events: require.resolve('events'),
http: require.resolve('stream-http'),
https: require.resolve('https-browserify'),
os: require.resolve('os-browserify/browser'),
path: require.resolve('path-browserify'),
punycode: require.resolve('punycode'),
process: require.resolve('process/browser'),
querystring: require.resolve('querystring-es3'),
stream: require.resolve('stream-browserify'),
string_decoder: require.resolve('string_decoder'),
sys: require.resolve('util'),
timers: require.resolve('timers-browserify'),
tty: require.resolve('tty-browserify'),
url: require.resolve('url'),
util: require.resolve('util'),
vm: require.resolve('vm-browserify'),
zlib: require.resolve('browserify-zlib'),
},
},
};
resolve.mainFields
[string]
When importing from an npm package, e.g. import * as D3 from 'd3'
, this option will determine which fields in its package.json
are checked. The default values will vary based upon the target
specified in your webpack configuration.
When the target
property is set to webworker
, web
, or left unspecified:
webpack.config.js
module.exports = {
//...
resolve: {
mainFields: ['browser', 'module', 'main'],
},
};
For any other target (including node
):
webpack.config.js
module.exports = {
//...
resolve: {
mainFields: ['module', 'main'],
},
};
For example, consider an arbitrary library called upstream
with a package.json
that contains the following fields:
{
"browser": "build/upstream.js",
"module": "index"
}
When we import * as Upstream from 'upstream'
this will actually resolve to the file in the browser
property. The browser
property takes precedence because it's the first item in mainFields
. Meanwhile, a Node.js application bundled by webpack will first try to resolve using the file in the module
field.
resolve.mainFiles
[string] = ['index']
The filename to be used while resolving directories.
webpack.config.js
module.exports = {
//...
resolve: {
mainFiles: ['index'],
},
};
resolve.exportsFields
[string] = ['exports']
Fields in package.json that are used for resolving module requests. See package-exports guideline for more information.
webpack.config.js
module.exports = {
//...
resolve: {
exportsFields: ['exports', 'myCompanyExports'],
},
};
resolve.modules
[string] = ['node_modules']
Tell webpack what directories should be searched when resolving modules.
Absolute and relative paths can both be used, but be aware that they will behave a bit differently.
A relative path will be scanned similarly to how Node scans for node_modules
, by looking through the current directory as well as its ancestors (i.e. ./node_modules
, ../node_modules
, and on).
With an absolute path, it will only search in the given directory.
webpack.config.js
module.exports = {
//...
resolve: {
modules: ['node_modules'],
},
};
If you want to add a directory to search in that takes precedence over node_modules/
:
webpack.config.js
const path = require('path');
module.exports = {
//...
resolve: {
modules: [path.resolve(__dirname, 'src'), 'node_modules'],
},
};
resolve.unsafeCache
RegExp
[RegExp]
boolean: true
Enable aggressive, but unsafe, caching of modules. Passing true
will cache everything.
webpack.config.js
module.exports = {
//...
resolve: {
unsafeCache: true,
},
};
A regular expression, or an array of regular expressions, can be used to test file paths and only cache certain modules. For example, to only cache utilities:
webpack.config.js
module.exports = {
//...
resolve: {
unsafeCache: /src\/utilities/,
},
};
resolve.plugins
A list of additional resolve plugins which should be applied. It allows plugins such as DirectoryNamedWebpackPlugin
.
webpack.config.js
module.exports = {
//...
resolve: {
plugins: [new DirectoryNamedWebpackPlugin()],
},
};
resolve.preferRelative
boolean
When enabled, webpack would prefer to resolve module requests as relative requests instead of using modules from node_modules
directories.
webpack.config.js
module.exports = {
//...
resolve: {
preferRelative: true,
},
};
src/index.js
// let's say `src/logo.svg` exists
import logo1 from 'logo.svg'; // this is viable when `preferRelative` enabled
import logo2 from './logo.svg'; // otherwise you can only use relative path to resolve logo.svg
// `preferRelative` is enabled by default for `new URL()` case
const b = new URL('module/path', import.meta.url);
const a = new URL('./module/path', import.meta.url);
resolve.preferAbsolute
boolean
Prefer absolute paths to resolve.roots
when resolving.
wepack.config.js
module.exports = {
//...
resolve: {
preferAbsolute: true,
},
};
resolve.symlinks
boolean = true
Whether to resolve symlinks to their symlinked location.
When enabled, symlinked resources are resolved to their real path, not their symlinked location. Note that this may cause module resolution to fail when using tools that symlink packages (like npm link
).
webpack.config.js
module.exports = {
//...
resolve: {
symlinks: true,
},
};
resolve.cachePredicate
function(module) => boolean
A function which decides whether a request should be cached or not. An object is passed to the function with path
and request
properties. It must return a boolean.
webpack.config.js
module.exports = {
//...
resolve: {
cachePredicate: (module) => {
// additional logic
return true;
},
},
};
resolve.restrictions
[string, RegExp]
A list of resolve restrictions to restrict the paths that a request can be resolved on.
webpack.config.js
module.exports = {
//...
resolve: {
restrictions: [/\.(sass|scss|css)$/],
},
};
resolve.roots
[string]
A list of directories where requests of server-relative URLs (starting with '/') are resolved, defaults to context
configuration option. On non-Windows systems these requests are resolved as an absolute path first.
webpack.config.js
const fixtures = path.resolve(__dirname, 'fixtures');
module.exports = {
//...
resolve: {
roots: [__dirname, fixtures],
},
};
resolve.importsFields
[string]
Fields from package.json
which are used to provide the internal requests of a package (requests starting with #
are considered internal).
webpack.config.js
module.exports = {
//...
resolve: {
importsFields: ['browser', 'module', 'main'],
},
};
Configure resolve options by the type of module request.
[type: string]: ResolveOptions
module.exports = {
// ...
resolve: {
byDependency: {
// ...
esm: {
mainFields: ['browser', 'module'],
},
commonjs: {
aliasFields: ['browser'],
},
url: {
preferRelative: true,
},
},
},
};
resolveLoader
object { modules [string] = ['node_modules'], extensions [string] = ['.js', '.json'], mainFields [string] = ['loader', 'main']}
This set of options is identical to the resolve
property set above, but is used only to resolve webpack's loader packages.
webpack.config.js
module.exports = {
//...
resolveLoader: {
modules: ['node_modules'],
extensions: ['.js', '.json'],
mainFields: ['loader', 'main'],
},
};
resolveLoader.moduleExtensions
[string]
The extensions/suffixes that are used when resolving loaders. Since version two, we strongly recommend using the full name, e.g. example-loader
, as much as possible for clarity. However, if you really wanted to exclude the -loader
bit, i.e. to only use example
, you can use this option to do so:
webpack.config.js
module.exports = {
//...
resolveLoader: {
moduleExtensions: ['-loader'],
},
};