1
|
# enhanced-resolve
|
2
|
|
3
|
Offers an async require.resolve function. It's highly configurable.
|
4
|
|
5
|
## Features
|
6
|
|
7
|
* plugin system
|
8
|
* provide a custom filesystem
|
9
|
* sync and async node.js filesystems included
|
10
|
|
11
|
|
12
|
## Getting Started
|
13
|
### Install
|
14
|
```sh
|
15
|
# npm
|
16
|
npm install enhanced-resolve
|
17
|
# or Yarn
|
18
|
yarn add enhanced-resolve
|
19
|
```
|
20
|
|
21
|
### Creating a Resolver
|
22
|
The easiest way to create a resolver is to use the `createResolver` function on `ResolveFactory`, along with one of the supplied File System implementations.
|
23
|
```js
|
24
|
const {
|
25
|
NodeJsInputFileSystem,
|
26
|
CachedInputFileSystem,
|
27
|
ResolverFactory
|
28
|
} = require('enhanced-resolve');
|
29
|
|
30
|
// create a resolver
|
31
|
const myResolver = ResolverFactory.createResolver({
|
32
|
// Typical usage will consume the `NodeJsInputFileSystem` + `CachedInputFileSystem`, which wraps the Node.js `fs` wrapper to add resilience + caching.
|
33
|
fileSystem: new CachedInputFileSystem(new NodeJsInputFileSystem(), 4000),
|
34
|
extensions: ['.js', '.json']
|
35
|
/* any other resolver options here. Options/defaults can be seen below */
|
36
|
});
|
37
|
|
38
|
// resolve a file with the new resolver
|
39
|
const context = {};
|
40
|
const resolveContext = {};
|
41
|
const lookupStartPath = '/Users/webpack/some/root/dir';
|
42
|
const request = './path/to-look-up.js';
|
43
|
myResolver.resolve({}, lookupStartPath, request, resolveContext, (err/*Error*/, filepath/*string*/) => {
|
44
|
// Do something with the path
|
45
|
});
|
46
|
```
|
47
|
|
48
|
For more examples creating different types resolvers (sync/async, context, etc) see `lib/node.js`.
|
49
|
#### Resolver Options
|
50
|
| Field | Default | Description |
|
51
|
| ------------------------ | --------------------------- | ---------------------------------------------------------------------------------- |
|
52
|
| alias | [] | A list of module alias configurations or an object which maps key to value |
|
53
|
| aliasFields | [] | A list of alias fields in description files |
|
54
|
| cacheWithContext | true | If unsafe cache is enabled, includes `request.context` in the cache key |
|
55
|
| descriptionFiles | ["package.json"] | A list of description files to read from |
|
56
|
| enforceExtension | false | Enforce that a extension from extensions must be used |
|
57
|
| enforceModuleExtension | false | Enforce that a extension from moduleExtensions must be used |
|
58
|
| extensions | [".js", ".json", ".node"] | A list of extensions which should be tried for files |
|
59
|
| mainFields | ["main"] | A list of main fields in description files |
|
60
|
| mainFiles | ["index"] | A list of main files in directories |
|
61
|
| modules | ["node_modules"] | A list of directories to resolve modules from, can be absolute path or folder name |
|
62
|
| unsafeCache | false | Use this cache object to unsafely cache the successful requests |
|
63
|
| plugins | [] | A list of additional resolve plugins which should be applied |
|
64
|
| symlinks | true | Whether to resolve symlinks to their symlinked location |
|
65
|
| cachePredicate | function() { return true }; | A function which decides whether a request should be cached or not. An object is passed to the function with `path` and `request` properties. |
|
66
|
| moduleExtensions | [] | A list of module extensions which should be tried for modules |
|
67
|
| resolveToContext | false | Resolve to a context instead of a file |
|
68
|
| fileSystem | | The file system which should be used |
|
69
|
| resolver | undefined | A prepared Resolver to which the plugins are attached |
|
70
|
|
71
|
## Plugins
|
72
|
Similar to `webpack`, the core of `enhanced-resolve` functionality is implemented as individual plugins that are executed using [`Tapable`](https://github.com/webpack/tapable). These plugins can extend the functionality of the library, adding other ways for files/contexts to be resolved.
|
73
|
|
74
|
A plugin should be a `class` (or its ES5 equivalent) with an `apply` method. The `apply` method will receive a `resolver` instance, that can be used to hook in to the event system.
|
75
|
|
76
|
### Plugin Boilerplate
|
77
|
```js
|
78
|
class MyResolverPlugin {
|
79
|
constructor(source, target) {
|
80
|
this.source = source;
|
81
|
this.target = target;
|
82
|
}
|
83
|
|
84
|
apply(resolver) {
|
85
|
const target = resolver.ensureHook(this.target);
|
86
|
resolver.getHook(this.source).tapAsync("MyResolverPlugin", (request, resolveContext, callback) => {
|
87
|
// Any logic you need to create a new `request` can go here
|
88
|
resolver.doResolve(target, request, null, resolveContext, callback);
|
89
|
});
|
90
|
}
|
91
|
}
|
92
|
```
|
93
|
|
94
|
Plugins are executed in a pipeline, and register which event they should be executed before/after. In the example above, `source` is the name of the event that starts the pipeline, and `target` is what event this plugin should fire, which is what continues the execution of the pipeline. For an example of how these different plugin events create a chain, see `lib/ResolverFactory.js`, in the `//// pipeline ////` section.
|
95
|
|
96
|
## Tests
|
97
|
|
98
|
``` javascript
|
99
|
npm test
|
100
|
```
|
101
|
|
102
|
[![Build Status](https://secure.travis-ci.org/webpack/enhanced-resolve.png?branch=master)](http://travis-ci.org/webpack/enhanced-resolve)
|
103
|
|
104
|
|
105
|
## Passing options from webpack
|
106
|
If you are using `webpack`, and you want to pass custom options to `enhanced-resolve`, the options are passed from the `resolve` key of your webpack configuration e.g.:
|
107
|
|
108
|
```
|
109
|
resolve: {
|
110
|
extensions: ['', '.js', '.jsx'],
|
111
|
modules: ['src', 'node_modules'],
|
112
|
plugins: [new DirectoryNamedWebpackPlugin()]
|
113
|
...
|
114
|
},
|
115
|
```
|
116
|
|
117
|
## License
|
118
|
|
119
|
Copyright (c) 2012-2016 Tobias Koppers
|
120
|
|
121
|
MIT (http://www.opensource.org/licenses/mit-license.php)
|