Webpack experience sharing

webpack is a module packager. Its main goal is to package JavaScript files together. The packaged files are used in the browser, but it can also be used for transformation, bundle or package. This article mainly shares Webpack with you. Some of my experiences, I hope it can help everyone.

Cache

Generate file name [name].[contenthash:8].js, combined with max-age + cdn for caching.

Webpage loading

html

It used to be a fixed html, html -"Version number js file (typed through webpack)-"Determine the specific js through the version number . (It doesn’t make sense now that I think about it, although it is not so heavily coupled with the backend)

Now is the changed html, which is typed out through HtmlWebpackPlugin (generated by webpack, containing js with the version number)

Like this It also saves a serial time (pulling the version number file). At the same time, it is also convenient to do grayscale. For example, if you publish the requirements, let some users experience it first, then dynamically type out the html and send it to the background. (Fixing html is not so easy)

css separation

In Guanmai, there will be very few css changes, thanks to react-gm's improvement of class names. Since there are few changes, it is not bad to separate the css and use ExtractTextPlugin to separate the css.

After separation, the size of js is reduced and js is not blocked. At the same time, css and js can be pulled at the same time.

common

new CommonsChunkPlugin({name: 'commons'})

Looking at the packaged common code, you will find that the IDs and hashes of other modules will be typed in common, so that the commons file will change every time, making it difficult to cache.

Just provide two file lists, and you will find that webpack puts the id and hash in the manifest file. This way commons can be cached. btw, I didn’t see any introduction on the official website, let me know if you do.

new CommonsChunkPlugin({names: ['commons', 'manifest']})

Local development

Let’s talk about agents. Local services are started by themselves. There is no background service, so naturally they need to be agents somewhere. Available via devServer.proxy. You can also use an agent to go to the external network to check for bugs. It is all source code, so bug checking is very fast.

"proxy": {
    "/ticket/*": {
      "target": "http://dev.guanmai.cn:7413",
      "changeOrigin": true
    }
}

Packaging speed

DllPlugin

When the project becomes large, it will inevitably require many packages, resulting in a very long packaging time. The official recommended approach is to make files that do not change frequently into DLLs.

Our project will react react-dom prop-types classnames mobx mobx-react lodash moment big.js Waiting for the call.

Online information all introduces that the file name of dll is [name]_[hash].dll.js, ours is [npm version]_dll.js npm version is package.json version read Come in.

Why not use hash but npm version? We encountered a problem when thinking about secondary packaging. How to judge whether the dll needs to be repackaged? What to do if it is hash (please recommend a solution). If you use npm version, we will repackage as soon as the version changes. For example, if react is upgraded, we will have version + and repackage.

happypack

happypack greatly improves the speed of build. It can be packaged in multiple threads, and the cache also speeds up rebuild.

devtool

Use eval for development and source-map for production (used to troubleshoot display problems, sacrificing packaging speed, within an acceptable range)

babel-loader

Remember cacheDirectory

noParse && alias

Some libraries do not need to be parsed, the noParse configuration does not parse, and alias points to the x.min.js file.

tree shaking

It’s not used yet, it feels like it’s not the right time yet. There is a good article. Your Tree-Shaking has no use.

Compression

UglifyJsPlugin

At the beginning, I used webpack.optimize.UglifyJsPlugin, which was 1.x at that time. version, webpack is based on uglify-js@2.x.

Now webpack has come out separately, and it has many more functions. It supports cache and multi-core compression. I tried it and it was quite fast. webpack.optimize.UglifyJsPlugin is actually uglifyjs-webpack-plugin.

What makes me curious is that the official said it is based on uglify-es. But I think the dependency is still uglify-js. strangeness.

UglifyJsParallelPlugin

Before the official release, I used webpack-uglify-parallel, which supports multi-core. The speed is not much different from uglifyjs-webpack-plugin.

When I wrote the article, I looked through github and found that it was abandoned in July and integrated into the official website.

Others

Babel-minify-webpack-plugin from babel, stay on the sidelines.

Script cdn

Some js (gm-fetch babel-polyfill) has very few changes. Packing with webpack is a bit wasteful. It can be obtained through cdn and put in script form into the html document. .

Analysis

There are charts and very intuitive analysis. I prefer it.
webpack-monitor

The old one is webpack-bundle-analyzer

Related recommendations:

Web example code for using webpack to build front-end projects

Summary of webpack configuration methods

Detailed explanation of npm and webpack configuration methods in node.js

The above is the detailed content of Webpack experience sharing. For more information, please follow other related articles on the PHP Chinese website!