@yued/autodll-webpack-plugin
Advanced tools
[](https://travis-ci.org/asfktz/autodll-webpack-plugin)
Webpack's DllPlugin without the boilerplate
npm install --save-dev autodll-webpack-plugin
Webpack's own DllPlugin it great, it can drastically reduce the amount of time needed to build (and rebuild) your bundles by reducing the amount of work needs to be done.
If you think about it, most of the code in your bundles come from NPM modules that you're rarely going to touch. You know that, but Webpack doesn't. So every time it compiles it has to analyze and build them too - and that takes time.
The DllPlugin allows you to to create a separate bundle in advance for all of those modules, and teach Webpack to reference them to that bundle instead.
That leads to a dramatic reduction in the amount of time takes Webpack to build your bundles.
For example, these are the measurements for the performance test that you can find in the examples folder:
| Without DllPlugin | With DllPlugin | |
|---|---|---|
| Build Time | 16461ms - 17310ms | 2991ms - 3505ms |
| DevServer Rebuild | 2924ms - 2997ms | 316ms - 369ms |
While the DllPlugin has many advantages, it's main drawback is that it requires a lot of boilerplate.
AutoDllPlugin serves as a high-level plugin for both the DllPlugin and the DllReferencePlugin, and hides away most of their complexity.
When you build your bundle for the first time, the AutoDllPlugin Compiles the DLL for you, and references all the specified modules from your bundle to the DLL.
The next time you compile your code, AutoDllPlugin will skip the build and read from the cache instead.
AutoDllPlugin will rebuild your DLLs every time you change the Plugin's configuration, install or remove a node module.
When using Webpack's Dev Server, the bundle are loaded into the memory preventing unnecessary reads from the FileSystem.
With the way the DLLPlugin works, you must load the DLL bundles before your own bundle. This is commonly accomplished by adding an additional script tag to the HTML.
Because that is such a common task, AutoDllPlugin can do this for you (in conjunction with the HtmlPlugin ).
plugins: [
new HtmlWebpackPlugin({
inject: true,
template: './src/index.html',
}),
new AutoDllPlugin({
inject: true, // will inject the DLL bundles to index.html
filename: '[name]_[hash].js',
entry: {
vendor: [
'react',
'react-dom',
'moment'
]
}
})
]
Will Result in:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Test</title>
</head>
<body>
...
<script src="dist/vendor.dll.js"></script>
<script src="dist/main.bundle.js"></script>
</body>
</html>
const webpack = require('webpack');
const path = require('path');
const AutoDllPlugin = require('autodll-webpack-plugin');
module.exports = {
entry: {
app: './src/index.js'
},
output: {
filename: '[name].bundle.js',
path: path.resolve(__dirname, 'dist')
publicPath: '/'
},
plugins: [
new AutoDllPlugin({
filename: '[name].dll.js',
entry: {
vendor: [
'react',
'react-dom',
'moment'
]
}
})
]
};
While it's not required, using AutoDllPlugin together with HtmlWebpackPlugin is highly recommended, because its saves you the trouble of manually adding the DLL bundles to the HTML by yourself.
Use AutoDllPlugin's inject option to enable this feature.
const webpack = require('webpack');
const path = require('path');
const AutoDllPlugin = require('autodll-webpack-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
entry: './src/index.js',
output: {
filename: '[name].bundle.js',
path: path.resolve(__dirname, 'dist'),
publicPath: '/'
},
plugins: [
new HtmlWebpackPlugin({
inject: true, // will inject the main bundle to index.html
template: './src/index.html',
}),
new AutoDllPlugin({
inject: true, // will inject the DLL bundle to index.html
debug: true,
filename: '[name]_[hash].js',
path: './dll',
entry: {
vendor: [
'react',
'react-dom',
'moment'
]
}
})
]
};
| Option | Type | Default | Description |
|---|---|---|---|
| entry | Object | {} |
The entry points for the DLL's. entry: {
// Create a DLL from NPM modules:
vendor: [
'react',
'react-dom',
'moment',
'lodash'
],
// Create a DLL from a part of your app
// that you rarely change:
admin: [
'./src/admin/index.js'
]
}
if you have multiple vendor and one has depend on another, for example, redux depend react:
entry: {
vendor: [
'react',
'react-dom',
'moment',
'lodash'
],
vendorRedux: [
'redux',
'react-redux'
]
}
you must make sure the keys in entry in order by the dependcy, like follow:
entry: {
vendor0: [
'react',
'react-dom',
'moment',
'lodash'
],
vendor1Redux: [
'redux',
'react-redux'
]
}
|
| filename | String | "[name].js" |
The filename template. Examples:
|
| context | String | process.cwd() |
The base directory, an absolute path, for resolving entry points and loaders from the configuration. Same as webpack's context
It is very important to make sure the context is set correctly, Most of the time, the defaults (the current directory) should work for you, here's how it should work: If your webpack config is stored at the base of your project: ~/my-project/webpack.config.js Set it up like this: {
context: __dirname
}
If your webpack config is stored in a nested directory: ~/my-project/config/webpack.config.js It should look like this: {
context: path.join(__dirname, '..')
}
|
| inject | Boolean | false |
By setting inject to true, AutoDLL will inject the DLL bundles into the HTML for you. Note: HtmlWebpackPlugin is required for this feature to work. |
| path | String | "" | The path for the DLL bundles, relative to webpack's output.publicPath |
| debug | Boolean | false | Use debug mode to see more clearly what AutoDLL is doing. |
| plugins | Array | [] |
Plugins for the DLL compiler. Same as webpack's plugins. plugins: [ new webpack.optimize.UglifyJsPlugin() ] |
When you run webpack for the first time, AutoDLL builds the DLL bundles and stores them in the cache for next time.
That leads to faster builds and rebuilds (using webpack's dev server).
There are two conditions for triggering a new build on the next run:
npm install / remove / update package-name (or Yarn equivalent).For performance considerations, AutoDLL is not aware of any changes made to module's files themselves.
So as long as you intend to work on a module, just exclude it from the DLL.
For example, let's say you configured the plugin like so:
new AutoDllPlugin({
entry: {
vendor: [
'react',
'react-dom',
'moment'
]
}
})
And then, while working on your project, you encountered some weird behavior with moment and decided to put a console.log statement in one of its files to see how it behaves.
As explained above, AutoDLL is not going to invalidate its cache in this case, and you might get surprised that you don't see the changes.
To fix that, all you have to do is comment out moment from the DLL, and uncomment it when you're done.
new AutoDllPlugin({
entry: {
vendor: [
'react',
'react-dom'
// 'moment'
]
}
})
That is most likely caused by using an incorrect context.
AutoDLL will try its best to set the context for you, but as with webpack's own context property, sometimes it is better to do it manually.
The context property should be an absolute path, pointing the base of your project.
For example, let's consider a project structured like so:
my-project
├── node_modules
│ └── react
│ └── react-dom
├── src
│ └── index.js
│ └── module.js
├── webpack.config.js
└── package.json
Then, inside webpack.config.js, You'll setup the context like so:
__dirname; // '/Users/username/my-project'
...
new AutoDllPlugin({
context: __dirname,
entry: {
vendor: [
'react',
'react-dom'
]
}
})
Note that the __dirname variable is node's way to get the absolute path of the current module's directly, which is exactly what we need because webpack.config.js stored in the base of our project.
On the other hand, let's say your project is structured like so:
my-project
├── node_modules
│ └── react
│ └── react-dom
├── src
│ └── index.js
│ └── module.js
├── config
│ └── webpack.config.js
└── package.json
Notice that now our config is no longer stored at the base of our project, but in a subdirectory of its own.
That means that now we have to subtract the relative path to our config file from __dirname.
We can use node's path module to help us with that:
var path = require('path');
__dirname; // '/Users/username/my-project/config'
path.join(__dirname, '..'); // '/Users/username/my-project'
...
new AutoDllPlugin({
context: path.join(__dirname, '..'),
entry: {
vendor: [
'react',
'react-dom'
]
}
})
If you still encounter an issue with the context set up correctly, please open an issue. I'll be happy to help you.
git clone git@github.com:asfktz/autodll-webpack-plugin.gitcd autodll-webpack-pluginnpm installcd examples/recommendednpm installnpm start or npm run buildFAQs
[](https://travis-ci.org/asfktz/autodll-webpack-plugin)
The npm package @yued/autodll-webpack-plugin receives a total of 0 weekly downloads. As such, @yued/autodll-webpack-plugin popularity was classified as not popular.
We found that @yued/autodll-webpack-plugin demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 6 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
Socket researchers have discovered malicious npm packages targeting crypto developers, stealing credentials and wallet data using spyware delivered through typosquats of popular cryptographic libraries.
Security News
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.
Security News
A Stanford study reveals 9.5% of engineers contribute almost nothing, costing tech $90B annually, with remote work fueling the rise of "ghost engineers."