webpack.js · Web軟件技術棧隨筆

[[webpack官方網站](https://webpack.js.org/)] **webpack** is a *static module bundler* for modern JavaScript applications. Webpack is used to compile JavaScript modules. Once installed, you can interface with webpack either from its `CLI` or `API`. An implementation of ES6 is free to do all the work at compile time and bundle all your modules into a single file to ship them over the network! And tools like [webpack](http://www.2ality.com/2015/04/webpack-es6.html) actually do this. [![webpack shield](https://img.shields.io/npm/v/webpack.svg?label=webpack&style=flat-square&maxAge=3600)](https://github.com/webpack/webpack/releases) webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset. Bundlers help you get your JavaScript and stylesheets ready for deployment, transforming them into a format that's suitable for the browser. For example, JavaScript can be [minified](https://webpack.js.org/plugins/terser-webpack-plugin) or [split into chunks](https://webpack.js.org/guides/code-splitting) and [lazy-loaded](https://webpack.js.org/guides/lazy-loading) to improve performance. Bundling is one of the most important challenges in web development, and solving it well can remove a lot of pain from the process. --- **目錄** [TOC] --- ## Core Concepts [[webpack官方網站 concepts](https://webpack.js.org/concepts/)] ### Entry [[webpack官方網站 Entry]](https://webpack.js.org/concepts/#entry) ### Output [[webpack官方網站 Output]](https://webpack.js.org/concepts/#output) ### Loaders [[webpack官方網站 Loaders]](https://webpack.js.org/concepts/#loaders) ### Plugins [[webpack官方網站 Plugins]](https://webpack.js.org/concepts/#plugins) ### Mode [[webpack官方網站 Mode]](https://webpack.js.org/concepts/#mode) ### Browser Compatibility [[webpack官方網站 Browser Compatibility]](https://webpack.js.org/concepts/#browser-compatibility) ## Development [[webpack官方網站 Development]](https://webpack.js.org/guides/development/) ### 4 methodes to watch effect after source code files had been modified 1. `npm run build` 2. `npm run watch` 3. `npm start` 4. `npm run server` * **package.json** ~~~ { "name": "webpack-demo", "version": "1.0.0", "description": "", "private": true, "scripts": { "test": "echo \"Error: no test specified\" && exit 1", //npm run build,dependency:webpack, 生成目標文件 "build": "webpack", //npm run watch,dependency:webpack --watch, //webpack's Watch Mode: 監視源文件的變化，有變化就編譯到目標文件 "watch": "webpack --watch", //npm start,dependency:webpack-dev-server // webpack-dev-server, 默認localhost:8080，啟動服務器端顯示源文件編譯后的實際情況 "start": "webpack-dev-server --open", //npm run server,dependency:webpack-dev-middleware // webpack-dev-middleware, 要設置localhost:???,還要寫server.js；啟動服務器端顯示源文件編譯后的實際情況，源文件有變化需手動刷新。 "server": "node server.js" }, "keywords": [], "author": "", "license": "ISC", //npm install --save-dev XX，應用 npm install 命令進行安裝的插件和依賴 "devDependencies": { "clean-webpack-plugin": "^3.0.0", "css-loader": "^3.0.0", "csv-loader": "^3.0.2", "express": "^4.17.1", "file-loader": "^4.0.0", "html-webpack-plugin": "^3.2.0", "lodash": "^4.17.11", "style-loader": "^0.23.1", "webpack": "^4.35.0", "webpack-cli": "^3.3.4", "webpack-dev-middleware": "^3.7.0", "webpack-dev-server": "^3.7.2", "xml-loader": "^1.2.1" } } ~~~ * **webpack.config.js** ~~~ javascript const path = require('path'); const HtmlWebpackPlugin = require('html-webpack-plugin'); const { CleanWebpackPlugin } = require('clean-webpack-plugin'); module.exports = { mode:'development', entry:{ app:'./src/index.js', print:'./src/print.js' }, devtool:'inline-source-map', devServer:{ contentBase:'./dist' }, plugins:[ new CleanWebpackPlugin(), new HtmlWebpackPlugin({ title:'Development' }) ], output: { filename: '[name].bundle.js', path: path.resolve(__dirname, 'dist'), publicPath:'/' } }; ~~~ >[info] `webpack-dev-server` doesn't write any output files after compiling. Instead, it keeps bundle files in memory and serves them as if they were real files mounted at the server's root path. If your page expects to find the bundle files in different path, you can change this with the[`publicPath`](https://webpack.js.org/configuration/dev-server/#devserver-publicpath-)option in the dev server's configuration. ### Hot Module Replacement(HMR) Hot Module Replacement (or HMR) is one of the most useful features offered by webpack. It allows all kinds of modules to be updated at runtime without the need for a full refresh. >[warning] **HMR** is not intended for use in production, meaning it should only be used in development. See the [building for production guide](https://webpack.js.org/guides/production) for more information. * Enabling HMR * Via the Node.js API ### Output Management 1. `HtmlWebpackPlugin`: by default it will generate its own `index.html` file. First install the plugin ~~~ bash npm install --save-dev html-webpack-plugin ~~~ then, adjust the`webpack.config.js`file: **webpack.config.js** ~~~diff const path = require('path'); + const HtmlWebpackPlugin = require('html-webpack-plugin'); module.exports = { entry: { app: './src/index.js', print: './src/print.js' }, + plugins: [ + new HtmlWebpackPlugin({ + title: 'Output Management' + }) + ], output: { filename: '[name].bundle.js', path: path.resolve(__dirname, 'dist') } }; ~~~ learn more about all the features and options that the`HtmlWebpackPlugin`provides, then you should read up on it on the[`HtmlWebpackPlugin`](https://github.com/jantimon/html-webpack-plugin)repo. 2. `clean-webpack-plugin`: clean the`/dist`folder before each build, [[官方文檔 `clean-webpack-plugin`]](https://www.npmjs.com/package/clean-webpack-plugin) First install the plugin ~~~ bash npm install --save-dev clean-webpack-plugin ~~~ then, adjust the`webpack.config.js`file: **webpack.config.js** ~~~diff const path = require('path'); const HtmlWebpackPlugin = require('html-webpack-plugin'); + const { CleanWebpackPlugin } = require('clean-webpack-plugin'); module.exports = { entry: { app: './src/index.js', print: './src/print.js' }, plugins: [ + new CleanWebpackPlugin(), new HtmlWebpackPlugin({ ? ? ? title: 'Output Management' }) ], output: { filename: '[name].bundle.js', path: path.resolve(__dirname, 'dist') } }; ~~~ 3. `WebpackManifestPlugin`: The manifest data can be extracted into a json file for easy consumption. [[官方文檔`WebpackManifestPlugin`]](https://github.com/danethurber/webpack-manifest-plugin). ### Code Splitting Webpack allows you to split your codebase into multiple chunks. Chunks are loaded asynchronously at runtime. This reduces the initial loading time. Code splitting is one of the most compelling features of webpack. This feature allows you to split your code into various **bundles which can then be loaded on demand or in parallel**. It can be used to achieve smaller bundles and control resource load prioritization which, if used correctly, can have a major impact on load time. There are three general approaches to code splitting available: * Entry Points: Manually split code using [`entry`](https://webpack.js.org/configuration/entry-context)configuration. * Prevent Duplication: Use the [`SplitChunksPlugin`](https://webpack.js.org/plugins/split-chunks-plugin/)to dedupe and split chunks. * Dynamic Imports: Split code via inline function calls within modules. `SplitChunksPlugin`: to extract common dependencies into an existing entry chunk or an entirely new chunk. >[warning] The`CommonsChunkPlugin`has been removed in webpack v4 legato. To learn how chunks are treated in the latest version, check out the [`SplitChunksPlugin`](https://webpack.js.org/plugins/split-chunks-plugin/). **webpack.config.js** ~~~diff const path = require('path'); module.exports = { mode: 'development', entry: { index: './src/index.js', another: './src/another-module.js' }, output: { filename: '[name].bundle.js', path: path.resolve(__dirname, 'dist') }, + optimization: { + splitChunks: { + chunks: 'all' + } + } }; ~~~ >[info] `optimization`: webpack can do many optimizations to **reduce the output size of your JavaScript** by deduplicating frequently used modules, minifying, and giving you full control of what is loaded initially and what is loaded at runtime through code splitting. It can also make your code chunks **cache friendly** by using hashes. Here are some other useful plugins and loaders provided by the community for splitting code: * [`mini-css-extract-plugin`](https://webpack.js.org/plugins/mini-css-extract-plugin): Useful for splitting CSS out from the main application. * [`bundle-loader`](https://webpack.js.org/loaders/bundle-loader): Used to split code and lazy load the resulting bundles. * [`promise-loader`](https://github.com/gaearon/promise-loader): Similar to the`bundle-loader`but uses promises. ### Dynamic Imports `import()` syntax: (recommended approach) conforms to the [ECMAScript proposal](https://github.com/tc39/proposal-dynamic-import) for dynamic imports. >[warning] `import()`calls use [promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) internally. If you use`import()`with older browsers, remember to shim`Promise`using a polyfill such as [es6-promise](https://github.com/stefanpenner/es6-promise) or [promise-polyfill](https://github.com/taylorhakes/promise-polyfill). As`import()`returns a promise, it can be used with[`async`functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function). However, this requires using a pre-processor like Babel and the [Syntax Dynamic Import Babel Plugin](https://babeljs.io/docs/plugins/syntax-dynamic-import/#installation). Here's how it would simplify the code: **src/index.js** ~~~javascript async function getComponent() { const element = document.createElement('div'); const { default: _} = await import(/* webpackChunkName: "lodash" */ 'lodash'); element.innerHTML = _.join(['Hello', 'webpack'], ' '); return element; } getComponent().then( com =>{ document.body.appendChild(com); }); ~~~ The reason we need`default`is that since webpack 4, when importing a CommonJS module (`lodash`), the `import` will no longer resolve to the value of`module.exports`, it will instead create an artificial namespace object for the CommonJS module. For more information on the reason behind this, read [webpack 4: import() and CommonJs](https://medium.com/webpack/webpack-4-import-and-commonjs-d619d626b655). Note the use of `webpackChunkName` in the comment. This will cause our separate bundle to be named `lodash.bundle.js` instead of just `[id].bundle.js`. For more information on `webpackChunkName` and the other available options, see the[`import()`documentation](https://webpack.js.org/api/module-methods#import-). Let's run webpack to see`lodash`separated out to a separate bundle: ~~~bash ... Asset Size Chunks Chunk Names index.bundle.js 7.88 KiB index [emitted] index vendors~lodash.bundle.js 547 KiB vendors~lodash [emitted] vendors~lodash Entrypoint index = index.bundle.js ... ~~~ ### Prefetching/Preloading modules ？？ ### Bundle Analysis ？？ Once you start splitting your code, it can be useful to analyze the output to check where modules have ended up. The [official analyze tool](https://github.com/webpack/analyse)is a good place to start. There are some other community-supported options out there as well: * [webpack-chart](https://alexkuz.github.io/webpack-chart/): Interactive pie chart for webpack stats. * [webpack-visualizer](https://chrisbateman.github.io/webpack-visualizer/): Visualize and analyze your bundles to see which modules are taking up space and which might be duplicates. * [webpack-bundle-analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer): A plugin and CLI utility that represents bundle content as a convenient interactive zoomable treemap. * [webpack bundle optimize helper](https://webpack.jakoblind.no/optimize): This tool will analyze your bundle and give you actionable suggestions on what to improve to reduce your bundle size. ### Lazy Loading Lazy, or "on demand", loading is a great way to optimize your site or application. This speeds up the initial load of the application and lightens its overall weight as some blocks may never even be loaded. Many frameworks and libraries have their own recommendations on how this should be accomplished within their methodologies. Here are a few examples: * React:[Code Splitting and Lazy Loading](https://reacttraining.com/react-router/web/guides/code-splitting) * Vue:[Lazy Load in Vue using Webpack's code splitting](https://alexjoverm.github.io/2017/07/16/Lazy-load-in-Vue-using-Webpack-s-code-splitting/) * Angular:[Lazy Loading route configuration](https://angular.io/guide/router#milestone-6-asynchronous-routing) * AngularJS:[AngularJS + Webpack = lazyLoad](https://medium.com/@var_bin/angularjs-webpack-lazyload-bb7977f390dd)by[@var\_bincom](https://twitter.com/var_bincom) ### Caching the configuration needed to ensure files produced by webpack compilation can remain cached unless their content has changed. We can use the `output.filename`[substitutions](https://webpack.js.org/configuration/output#output-filename) setting to define the names of our output files. webpack provides a method of templating the filenames using bracketed strings called **substitutions**. The `[contenthash]` substitution will add a unique hash based on the content of an asset. When the asset's content changes, `[contenthash]` will change as well. **webpack.config.js** ~~~diff const path = require('path'); const { CleanWebpackPlugin } = require('clean-webpack-plugin'); const HtmlWebpackPlugin = require('html-webpack-plugin'); module.exports = { entry: './src/index.js', plugins: [ // new CleanWebpackPlugin(['dist/*']) for < v2 versions of CleanWebpackPlugin new CleanWebpackPlugin(), new HtmlWebpackPlugin({ ? ? ? title: 'Caching' }) ], output: { - filename: 'bundle.js', + filename: '[name].[contenthash].js', path: path.resolve(__dirname, 'dist') } }; ~~~ Running our build script,`npm run build`, with this configuration should produce the following output: ~~~bash ... Asset Size Chunks Chunk Names main.7e2c49a622975ebd9b7e.js 544 kB 0 [emitted] [big] main index.html 197 bytes [emitted] ... ~~~ As you can see the bundle's name now reflects its content (via the hash). If we run another build without making any changes, we'd expect that filename to stay the same. **Extracting Boilerplate** Webpack provides an optimization feature to split runtime code into a separate chunk using the [`optimization.runtimeChunk`](https://webpack.js.org/configuration/optimization/#optimization-runtimechunk) option. Set it to `single` to create a single runtime bundle for all chunks. Webpack provides `optimization.splitChunks` with `cacheGroups` to extract third-party libraries, such as `lodash` or `react`, to a separate `vendor` chunk as they are less likely to change than our local source code.This step will allow clients to request even less from the server to stay up to date. **webpack.config.js** ~~~diff const path = require('path'); const { CleanWebpackPlugin } = require('clean-webpack-plugin'); const HtmlWebpackPlugin = require('html-webpack-plugin'); module.exports = { entry: './src/index.js', plugins: [ // new CleanWebpackPlugin(['dist/*']) for < v2 versions of CleanWebpackPlugin new CleanWebpackPlugin(), new HtmlWebpackPlugin({ ? ? ? title: 'Caching' }), ], output: { filename: '[name].[contenthash].js', path: path.resolve(__dirname, 'dist') }, optimization: { runtimeChunk: 'single', + splitChunks: { + cacheGroups: { + vendor: { + test: /[\\/]node_modules[\\/]/, + name: 'vendors', + chunks: 'all' + } + } + } } }; ~~~ Let's run another build to see our new`vendor`bundle: ~~~bash ... Asset Size Chunks Chunk Names runtime.cc17ae2a94ec771e9221.js 1.42 KiB 0 [emitted] runtime vendors.a42c3ca0d742766d7a28.js 69.4 KiB 1 [emitted] vendors main.abf44fedb7d11d4312d7.js 240 bytes 2 [emitted] main index.html 353 bytes [emitted] ... ~~~ We can now see that our`main`bundle does not contain `vendor` code from `node_modules` directory and is down in size to `240 bytes`! **Module Identifiers** `NamedModulesPlugin`: it will uses the path to the module rather than a numerical identifier. While this plugin is useful during development for more readable output, it does take a bit longer to run. [`HashedModuleIdsPlugin`](https://webpack.js.org/plugins/hashed-module-ids-plugin): recommended for production builds: **webpack.config.js** ~~~diff + const webpack = require('webpack'); module.exports = { plugins: [ + new webpack.HashedModuleIdsPlugin() ], }; ~~~ ### Authoring Libraries ?? [[webpack官方網站 author-libraries]](https://webpack.js.org/guides/author-libraries/) Aside from applications, webpack can also be used to bundle JavaScript libraries. You can [publish it as an npm package](https://docs.npmjs.com/getting-started/publishing-npm-packages) and find it at [unpkg.com](https://unpkg.com/#/) to distribute it to your users. ### Environment Variables [[webpack官方網站 environment-variables]](https://webpack.js.org/guides/environment-variables/) ### Module [[webpack官方網站-Module](https://webpack.js.org/concepts/modules/)] In contrast to [Node.js modules](https://nodejs.org/api/modules.html), webpack *modules* can express their *dependencies* in a variety of ways. A few examples are: * An [ES2015 `import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) statement * A [CommonJS](http://www.commonjs.org/specs/modules/1.0/) `require()` statement * An [AMD](https://github.com/amdjs/amdjs-api/blob/master/AMD.md) `define` and `require` statement * An [`@import` statement](https://developer.mozilla.org/en-US/docs/Web/CSS/@import) inside of a css/sass/less file. * An image url in a stylesheet (`url(...)`) or html (`<img src=...>`) file. >[info] webpack 1 requires a specific loader to convert ES2015 `import`, however this is possible out of the box via webpack 2 #### Supported Module Types webpack supports modules written in a variety of languages and preprocessors, via *loaders*. *Loaders* describe to webpack **how** to process non-JavaScript *modules* and include these *dependencies* into your *bundles*. The webpack community has built *loaders* for a wide variety of popular languages and language processors, including: * [CoffeeScript](http://coffeescript.org) * [TypeScript](https://www.typescriptlang.org) * [ESNext (Babel)](https://babeljs.io) * [Sass](http://sass-lang.com) * [Less](http://lesscss.org) * [Stylus](http://stylus-lang.com) And many others! Overall, webpack provides a powerful and rich API for customization that allows one to use webpack for **any stack**, while staying **non-opinionated** about your development, testing, and production workflows. module.export loader import/require ## Production [[webpack官方網站 Production]](https://webpack.js.org/guides/production/) ## Tree Shaking [[webpack官方網站 Tree-shaking]](https://webpack.js.org/guides/tree-shaking/) **Tree shaking** is a term commonly used in the JavaScript context for dead-code elimination. It relies on the [static structure](http://exploringjs.com/es6/ch_modules.html#static-module-structure) of ES2015 module syntax, i.e. `import` and `export`. in order to take advantage of `tree shaking`, you must... * Use ES2015 module syntax (i.e.`import`and`export`). * Ensure no compilers transform your ES2015 module syntax into CommonJS modules (this is the default behavior of popular Babel preset @babel/preset-env - see [documentation](https://babeljs.io/docs/en/babel-preset-env#modules) for more details). * Add a `"sideEffects"` property to your project's `package.json` file. * Use `production` `mode`configuration option to enable various `optimizations` including minification and tree shaking. You can imagine your application as a tree. The source code and libraries you actually use represent the green, living leaves of the tree. Dead code represents the brown, dead leaves of the tree that are consumed by autumn. In order to get rid of the dead leaves, you have to shake the tree, causing them to fall. ## 待求證 1. [設置webpack，在JS文件中使用es6的語法](https://blog.csdn.net/a250758092/article/details/78543440)