1 | # HardSourceWebpackPlugin
|
2 |
|
3 | [![Build Status](https://travis-ci.org/mzgoddard/hard-source-webpack-plugin.svg?branch=master)](https://travis-ci.org/mzgoddard/hard-source-webpack-plugin) [![Build status](https://ci.appveyor.com/api/projects/status/761saaelxem01xo5/branch/master?svg=true)](https://ci.appveyor.com/project/mzgoddard/hard-source-webpack-plugin/branch/master)
|
4 |
|
5 | `HardSourceWebpackPlugin` is a plugin for webpack to provide an intermediate caching step for modules. In order to see results, you'll need to run webpack twice with this plugin: the first build will take the normal amount of time. The second build will be signficantly faster.
|
6 |
|
7 | Install with `npm install --save hard-source-webpack-plugin` or `yarn`. And include the plugin in your webpack's plugins configuration.
|
8 |
|
9 | ```js
|
10 | // webpack.config.js
|
11 | var HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
|
12 |
|
13 | module.exports = {
|
14 | context: // ...
|
15 | entry: // ...
|
16 | output: // ...
|
17 | plugins: [
|
18 | new HardSourceWebpackPlugin()
|
19 | ]
|
20 | }
|
21 | ```
|
22 |
|
23 | You can optionally set where HardSource writes and reads its cache to and from, and the hash values that determine when it creates new caches.
|
24 |
|
25 | ```js
|
26 | new HardSourceWebpackPlugin({
|
27 | // Either an absolute path or relative to webpack's options.context.
|
28 | cacheDirectory: 'node_modules/.cache/hard-source/[confighash]',
|
29 | // Either a string of object hash function given a webpack config.
|
30 | configHash: function(webpackConfig) {
|
31 | // node-object-hash on npm can be used to build this.
|
32 | return require('node-object-hash')({sort: false}).hash(webpackConfig);
|
33 | },
|
34 | // Either false, a string, an object, or a project hashing function.
|
35 | environmentHash: {
|
36 | root: process.cwd(),
|
37 | directories: [],
|
38 | files: ['package-lock.json', 'yarn.lock'],
|
39 | },
|
40 | // An object.
|
41 | info: {
|
42 | // 'none' or 'test'.
|
43 | mode: 'none',
|
44 | // 'debug', 'log', 'info', 'warn', or 'error'.
|
45 | level: 'debug',
|
46 | },
|
47 | }),
|
48 | ```
|
49 |
|
50 | ## Options
|
51 |
|
52 | ### `cacheDirectory`
|
53 |
|
54 | The `cacheDirectory` is where the cache is written to. The default stores the cache in a directory under node_modules so if node_modules is cleared so is the cache.
|
55 |
|
56 | The `cacheDirectory` has a field in it `[confighash]` that is replaced by the `configHash` option when webpack is started. The `[confighash]` field is here to help with changes to the configuration by the developer or by a script. For example if the same webpack configuration is used for the `webpack` cli tool and then the `webpack-dev-server` cli tool, they will generate different configuration hashes. `webpack-dev-server` adds plugins for its reloading features, and the default hash function produces a different value with those plugins added.
|
57 |
|
58 | ### `configHash`
|
59 |
|
60 | <a name="using-confighash-in-the-cachedirectory"></a>
|
61 | <a name="why-hash-the-config"></a>
|
62 |
|
63 | `configHash` turns a webpack configuration when a webpack instance is started and is used by `cacheDirectory` to build different caches for different webpack configurations.
|
64 |
|
65 | Configurations may change how modules are rendered and so change how they appear in the disk cache `hard-source` writes. It is important to use a different cache per webpack configuration or webpack cli tool. `webpack` and `webpack-dev-server` for example needed separate caches, `configHash` and `[confighash]` in the `cacheDirectory` will create separate caches due to the plugins and configuration changes `webpack-dev-server` makes.
|
66 |
|
67 | The default value for `configHash` is
|
68 |
|
69 | ```js
|
70 | configHash: function(webpackConfig) {
|
71 | return require('node-object-hash')({sort: false}).hash(webpackConfig);
|
72 | }
|
73 | ```
|
74 |
|
75 | This uses the npm `node-object-hash` module with sort set to false to hash the object. `node-object-hash` hashes as much as it can but may have issue with some plugins or plugins and loaders that load an additional configuration file like a babel rc file or postcss config. In those cases you can depend on `node-object-hash` and extend what it hashes to best cover those changes.
|
76 |
|
77 | `configHash` can also be set to a string or it can be a function that generates a value based on other parts of the environment.
|
78 |
|
79 | ```js
|
80 | configHash: function() {
|
81 | return process.env.NODE_ENV + '-' process.env.BABEL_ENV;
|
82 | }
|
83 | ```
|
84 |
|
85 | ### `environmentHash`
|
86 |
|
87 | When loaders, plugins, other build time scripts, or other dynamic dependencies change, `hard-source` needs to replace the cache to make sure the output is correct. The `environmentHash` is used to determine this. If the hash is different than a previous build, a fresh cache will be used.
|
88 |
|
89 | The default object
|
90 |
|
91 | ```js
|
92 | environmentHash: {
|
93 | root: process.cwd(),
|
94 | directories: [],
|
95 | files: ['package-lock.json', 'yarn.lock']
|
96 | }
|
97 | ```
|
98 |
|
99 | hashes the lock files for `npm` and `yarn`. They will both be used if they both exist, or just one if only one exists. If neither file is found, the default will hash `package.json` and the `package.json` under `node_modules`.
|
100 |
|
101 | <a name="environmenthash-as-a-function"></a>
|
102 | <a name="environmenthash-as-an-object"></a>
|
103 |
|
104 | <a name="environmenthash-disabled-with-false"></a>
|
105 |
|
106 | You can disable the environmentHash by setting it to `false`. By doing this you will manually need to delete the cache when there is any dependency environment change.
|
107 |
|
108 | ### `info`
|
109 |
|
110 | Control the amount of messages from hard-source.
|
111 |
|
112 | #### `mode`
|
113 |
|
114 | Sets other defaults for info. Defaults to 'test' when NODE_ENV==='test'.
|
115 |
|
116 | #### `level`
|
117 |
|
118 | The level of log messages to report down to. Defaults to 'debug' when mode is 'none'. Defaults to 'warn' when mode is 'test'.
|
119 |
|
120 | For example 'debug' reports all messages while 'warn' reports warn and error level messages.
|
121 |
|
122 | ## Troubleshooting
|
123 |
|
124 | ### Configuration changes are not being detected
|
125 |
|
126 | `hard-source` needs a different cache for each different webpack configuration. The default `configHash` may not detect all of your options to plugins or other configuration files like `.babelrc` or `postcss.config.js`. In those cases a custom `configHash` is needed hashing the webpack config and those other values that it cannot normally reach.
|
127 |
|
128 | ### Hot reloading is not working
|
129 |
|
130 | `webpack-dev-server` needs a different cache than `webpack` or other webpack cli tools. Make sure your `cacheDirectory` and `configHash` options are hashing the changes `webpack-dev-server` makes to your webpack config. The default `hard-source` values should do this.
|
131 |
|
132 | ### Multiple webpack processes at the same time are getting bad results
|
133 |
|
134 | If you are using multiple webpack instances in separate processes make sure each has its own cache by changing `cacheDirectory` or `configHash`.
|
135 |
|
136 | ### Rebuilds are slower than the first build during dev-server
|
137 |
|
138 | This is can be due to module context dependencies. `require.context` or loaders that watch folders use this webpack feature so webpack rebuilds when files or folders are added or removed from these watched directories. Be careful about using `require.context` or context aware loaders on folders that contain a lot of items. Both `require.context` and context loaders depend on those folders recursively. `hard-source` hashes every file under a `require.context` or context loader folder to detect when the context has changed and dependent modules are rebuilt.
|
139 |
|
140 | ### `webpack-dev-server` build loops continuously
|
141 |
|
142 | Make sure you don't have a `require.context` or context loader on the root of your project. Such a context module means webpack is watching the hard source cache and when the cache is written after a build, webpack will start a new build for that module. This normally does not happen with `webpack-dev-server` because it writes the built files into memory instead of the disk. `hard-source` cannot do that since that would defeat its purpose as a disk caching plugin.
|
143 |
|
144 | ## Please contribute!
|
145 |
|
146 | If you encounter any issues or have an idea for hard-source-webpack-plugin could be better, please let us know.
|
147 |
|
148 | # [Change Log](CHANGELOG.md)
|