HTTPS clone URL
Subversion checkout URL
- api in modules
- build performance
- code splitting
- dev tools
- hot module replacement
- hot module replacement with webpack
- how to write a loader
- how to write a plugin
- internal webpack plugins
- library and externals
- list of hints
- list of loaders
- list of plugins
- list of tutorials
- loader conventions
- long term caching
- multiple entry points
- node.js api
- shimming modules
- usage with bower
- usage with grunt
- usage with gulp
- usage with karma
- Usage with Visual Studio
- using loaders
- using plugins
- webpack dev middleware
- webpack dev server
- webpack for browserify users
- webpack options
- what is webpack
Clone this wiki locally
The resolving process is pretty simple. We distinguish three types of requests:
- absolute path:
- relative path:
- module path:
We first check if the path points to a directory. For a directory we need to find the main file in this directory. Therefore the
main field in the
package.json is joined to the path. If there is no
package.json or no
index is used as filename.
We have an absolute path to a file now. We try to append all extensions (configuration option
resolve.extensions). The first existing file is used as result.
The context directory is the directory of the resource file that contains the
require statement. If there is no resource file the configuration option
context is used as context directory. (This can occur for entry points or with loader-generated files).
The relative path is joined to the context directory and the resulting absolute file is resolved according to "Resolving an absolute path".
For resolving a module we first gather all search directories for modules from the context directory. This process is similar to the node.js resolving process, but the search directories are configurable with the configuration option
resolve.modulesDirectories. In addition to this the directories in the configuration option
resolve.root are prepended and directories in the configuration option
resolve.fallback are appended.
The module is looked up in each module directory and resolved according to "Resolving an absolute path". If the first match has no success, the second is tried and so on.
There is a configuration option
resolve.alias which renames modules.
When trying to "resolve a module path" the module name is matched to the
resolve.alias option and when there is a match it gets replaced with the alias.
Every filesystem access is cached so that multiple parallel or serial requests to the same thing are merged. In watching mode only changed files are removed from cache (the watcher knows which files got changed). In non-watching mode the cache is purged before every compilation.
There is a configuration option
resolve.unsafeCache which boosts performance by aggressive caching.
Every resolve process is cached and isn't ever purged. This is correct in most cases, but incorrect in edge cases (what edge cases?).
When trying to resolve a context "Resolving an absolute path" ends when a directory is found.
For loaders the configuration options in
resolveLoader are used.
In addition to that when trying to "resolve a module path" all module name variations in the configuration option
resolveLoader.moduleTemplates are tried.
The above description suggests a serial process, but in the implementation the process is completely asynchronous and parallel. This may causes more filesystem access than required.