百科.dev
全部条目AI 编程趋势榜开源项目技术资讯提交条目
登录
< 返回工具列表
A

autodll-webpack-plugin

> 编程语言
开源

Webpack 的 DllPlugin,无需模板

1.4K stars0 点赞1 次浏览
访问官网GitHub

工具介绍

Webpack 的 DllPlugin,无需模板

# Important Note Now, that webpack 5 planning to [support caching out-of-the-box](https://github.com/webpack/webpack/issues/6527), AutoDllPlugin will soon be obsolete. In the meantime, I would like to recommend Michael Goddard's [hard-source-webpack-plugin](https://github.com/mzgoddard/hard-source-webpack-plugin),
which seems like webpack 5 is going to use internally.
# AutoDllPlugin Webpack's DllPlugin without the boilerplate webpack 4 ``` npm install --save-dev autodll-webpack-plugin ``` webpack 2 / 3 ``` npm install --save-dev [email protected] ``` --- ## Table of contents - [Introduction](#introduction) - [Options](#options) - [FAQ](#faq) - [Examples](#running-examples) ## Introduction 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](examples/performance) that you can find in the [examples](examples) folder: | | **Without DllPlugin** | **With DllPlugin** | |-------------------|-------------------|-----------------------| | **Build Time** | 16461ms - 17310ms | 2991ms - 3505ms | | **DevServer Rebuild** | 2924ms - 2997ms | 316ms - 369ms | ### The DllPlugin sounds great! So why AutoDllPlugin? 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 ). ```js plugins: [ new HtmlWebpackPlugin({ inject: true, template: './src/index.html', }), new AutoDllPlugin({    inject: true, // will inject the DLL bundles to index.html filename: '[name].js', entry: { vendor: [ 'react', 'react-dom' ] } }) ] ``` Will Result in: ```html Test ...     ``` ### Basic Usage ([example](examples/basic)): ```js 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' ] } }) ] }; ``` ### Recommended Usage ([example](examples/recommended)): While it's not required, using AutoDllPlugin together with [HtmlWebpackPlugin](https://github.com/jantimon/html-webpack-plugin) 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. ``` … ``` ## Options Option Type Default Description entry Object {}

The entry points for the DLL's.
Think of it as the entry option in your webpack config.
Each entry point represents a DLL bundle and expects an array of modules.

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'
    ]
}
filename String "[name].js"

The filename template.
Same as webpack's output.filename.

Examples:

  • [name]_[hash].dll.js
  • [id].bundle.js
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,
otherwise, you'll end up with having the same modules both in the DLL bundles and in your main bundles!

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()
]
inherit Boolean/Function false Inherit from the parent config. A valid use-case would be if you have devtool: "source-maps" in your webpack config and wanted source maps to be created for the DLL bundle as well. However, this does not inherit plugins from the parent config and inheriting loaders are buggy too(see #37). It can also be a function to inherit only the desired properties.
function inherit(webpackConfig) {
  // Return object with desired properties.
}
To see it action, check out the example.
⚠️ This option is highly experimental! Use with caution and if you face any problems, please open a issue. ## FAQ ### I added my dependencies to the DLL, and now, when I make a change to one of them I don't see it! Why? 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: 1. Running `npm install / remove / update package-name` (or Yarn equivalent). 2. Changing the plugin's configurations. 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: ```js new AutoDllPlugin({ entry: { vendor: [ 'react', 'react-dom', 'lodash' ] } }) ``` And then, while working on your project, you encountered some weird behavior with `lodash` 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 `lodash` from the DLL, and uncomment it when you're done. ```js new AutoDllPlugin({ entry: { vendor: [ 'react', 'react-dom' // 'lodash' ] } }) ``` ### The modules I added to the DLL are duplicated! They included both in the DLL bundle AND the main bundle. 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](https://webpack.js.org/configuration/entry-context/#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: ```js __dirname; // '/Users/username/my-project' ... new AutoDllPlugin({ context: __dirname, entry: { vendor: [ 'react', 'react-dom' ] } }) ``` Note that the `__dirname` variable is [node's way](https://nodejs.org/docs/latest/api/globals.html#globals_dirname) to get the absolute path of the current module's direct

GitHub Issues· 56 开放

在 GitHub 查看全部
  • #150

    Cannot add property autodllStatsRetrieved, object is not extensible

    更新于 2023年8月12日
  • #151

    how to use this plugin with create-react-app & craco ?

    更新于 2023年4月18日
  • #148

    inject the DLL bundles into the html fail

    更新于 2020年10月1日
  • #149

    add path parameter html script src can add /

    更新于 2020年9月18日
  • #124

    How to DevExpress to DLL?

    更新于 2020年7月28日
  • #137

    multiple dll packages are generated, it will cause duplicate references

    更新于 2020年4月14日
  • #147

    what is the right context for a monorepo setup?

    更新于 2020年1月8日
  • #146

    Autodll-webpack-plugin specifying node_modules in different projects

    更新于 2020年1月6日
  • #145

    Plugins are not run when cache is valid

    更新于 2019年12月12日
  • #144

    How do I set entryOnly to true to enable treeshaking?

    更新于 2019年12月12日

核心特点

  • •JavaScript

> 标签

JavaScript

暂无评论,来聊聊你的看法吧

> 工具信息

发布日期2026年8月1日
最后更新2026年9月17日
分类编程语言
定价开源

> 相关工具

T
TypeScript
JavaScript 的超集,为前端与全栈提供静态类型
P
Python
通用编程语言,广泛用于 Web、数据与 AI
G
Go
Google 推出的简洁高效系统语言