|
1 | 1 | ---
|
2 |
| -title: Resolver |
| 2 | +title: Resolvers |
3 | 3 | group: Plugins
|
4 | 4 | sort: 3
|
5 | 5 | ---
|
6 | 6 |
|
7 |
| -There are three types of resolvers, each used for different types of modules: |
| 7 | +Resolvers are created using the `enhanced-resolve` package. The `Resolver` |
| 8 | +class extends the `tapable` class and uses `tapable` to provide a few hooks. |
| 9 | +The `enhanced-resolve` package can be used directly to create new resolvers, |
| 10 | +however any [`compiler` instance]() has a few resolver instances that can be |
| 11 | +tapped into. |
8 | 12 |
|
9 |
| -- `compiler.resolvers.normal`: Resolve a normal module. |
10 |
| -- `compiler.resolvers.context`: Resolve a context module. |
11 |
| -- `compiler.resolvers.loader`: Resolve a loader. |
| 13 | +Before reading on, make sure you at least skim through the |
| 14 | +[`enhanced-resolve`]() and [`tapable`]() documentation. |
12 | 15 |
|
13 |
| -Any plugin should use `this.fileSystem` as fileSystem, as it's cached. It only has async named functions, but they may behave sync, if the user uses a sync file system implementation (i. e. in enhanced-require). |
14 | 16 |
|
15 |
| -To join paths any plugin should use `this.join`. It normalizes the paths. There is a `this.normalize` too. |
| 17 | +## Types |
16 | 18 |
|
17 |
| -A bailing async `forEach` implementation is available on `this.forEachBail(array, iterator, callback)`. |
| 19 | +There are three types of built-in resolvers available on the `compiler` class: |
18 | 20 |
|
19 |
| -To pass the request to other resolving plugins, use the `this.doResolve(types: String|String[], request: Request, message: String, callback)` method. `types` are multiple possible request types that are tested in order of preference. |
| 21 | +- Normal: Resolves a module via an absolute or relative path. |
| 22 | +- Context: Resolves a module within a given context. |
| 23 | +- Loader: Resolves a webpack [loader](/loaders). |
20 | 24 |
|
21 |
| -``` js |
22 |
| -interface Request { |
23 |
| - path: String // The current directory of the request |
24 |
| - request: String // The current request string |
25 |
| - query: String // The query string of the request, if any |
26 |
| - module: boolean // The request begins with a module |
27 |
| - directory: boolean // The request points to a directory |
28 |
| - file: boolean // The request points to a file |
29 |
| - resolved: boolean // The request is resolved/done |
30 |
| - // undefined means false for boolean fields |
31 |
| -} |
| 25 | +Depending on need, any one of these built-in resolver used by the `compiler` |
| 26 | +can be customized via plugins as such: |
32 | 27 |
|
33 |
| -// Examples |
34 |
| -// from /home/user/project/file.js: require("../test?charset=ascii") |
35 |
| -{ |
36 |
| - path: "/home/user/project", |
37 |
| - request: "../test", |
38 |
| - query: "?charset=ascii" |
39 |
| -} |
40 |
| -// from /home/user/project/file.js: require("test/test/") |
41 |
| -{ |
42 |
| - path: "/home/user/project", |
43 |
| - request: "test/test/", |
44 |
| - module: true, |
45 |
| - directory: true |
46 |
| -} |
| 28 | +``` js |
| 29 | +compiler.resolverFactory.plugin('resolver [type]', resolver => { |
| 30 | + resolver.hooks.resolve.tapAsync('MyPlugin', params => { |
| 31 | + // ... |
| 32 | + }) |
| 33 | +}) |
47 | 34 | ```
|
48 | 35 |
|
| 36 | +Where `[type]` is one of the three resolvers mention above, specified as: |
49 | 37 |
|
50 |
| -## `resolve(context: String, request: String)` |
51 |
| - |
52 |
| -Before the resolving process starts. |
53 |
| - |
54 |
| - |
55 |
| -## `resolve-step(types: String[], request: Request)` |
56 |
| - |
57 |
| -Before a single step in the resolving process starts. |
58 |
| - |
59 |
| - |
60 |
| -## `module(request: Request)` async waterfall |
61 |
| - |
62 |
| -A module request is found and should be resolved. |
63 |
| - |
64 |
| - |
65 |
| -## `directory(request: Request)` async waterfall |
66 |
| - |
67 |
| -A directory request is found and should be resolved. |
68 |
| - |
69 |
| - |
70 |
| -## `file(request: Request)` async waterfall |
71 |
| - |
72 |
| -A file request is found and should be resolved. |
73 |
| - |
74 |
| - |
75 |
| -## The plugins may offer more extensions points |
76 |
| - |
77 |
| -Here is a list what the default plugins in webpack offer. They are all `(request: Request)` async waterfall. |
78 |
| - |
79 |
| -The process for normal modules and contexts is `module -> module-module -> directory -> file`. |
80 |
| - |
81 |
| -The process for loaders is `module -> module-loader-module -> module-module -> directory -> file`. |
82 |
| - |
83 |
| - |
84 |
| -## `module-module` |
| 38 | +- `normal` |
| 39 | +- `context` |
| 40 | +- `loader` |
85 | 41 |
|
86 |
| -A module should be looked up in a specified directory. `path` contains the directory. |
| 42 | +See the `enhanced-resolve` [documentation]() for a full list of hooks and |
| 43 | +descriptions. |
87 | 44 |
|
88 | 45 |
|
89 |
| -## `module-loader-module` (only for loaders) |
| 46 | +## Configuration Options |
90 | 47 |
|
91 |
| -Used before module templates are applied to the module name. The process continues with `module-module`. |
| 48 | +Briefly discuss and link to resolver-related configuration docs. Clarify how |
| 49 | +the options affect the three different resolvers... |
0 commit comments