Webpack, the most widely used front-end packaging tool, has become part of the front-end engineering infrastructure. It’s been 18 years since the last major release of Webpack. Two years later, let’s take a look at what Webpack5 has brought to the table and how it helps our application.

An overview of

The following picture is a screenshot from the official Changelog of Webpack. It can be seen that there are major improvements in these aspects:

  • Improve performance with persistent caching
  • Adopt better persistent caching algorithms and default behavior
  • Reduce Bundle size by optimizing Tree Shaking and code generation
  • Improve Web platform compatibility
  • Clear unreasonable state caused by the previous implementation of Webpack4 without incompatible changes
  • Try to introduce significant changes now to prepare for future features to allow us to use Webpack 5 for as long as possible

I have to say that the official announcement is a little bit sketchy, only mentioning persistent cache optimization and better Tree Shaking, Module federation. The following is a look at the specific parts of the upgrade.

Outdated features removed

  • The first is to remove the Warning function in Webpack4.
  • Both IgnorePlugin and BannerPlugin must now pass in a parameter, which can be Object, String, or Function
  • require.includeSyntax deprecated, Warning when used. Of course this behavior can passRule.parser.requireIncludeChange this syntax to allowed, deprecated, or disabled
  • Remove automatic node.js Polyfills. In the early days of Webpack, the main purpose of Webpack was to make Node.js modules run in browsers. However, as the module pattern changes, more and more modules are used only in browsers. In this case, Polyfills some Node modules (such as Crypto) will automatically increase the packaging size. This automatic behavior was removed after Webpack5

The cache for a long time

  • Deterministic module, module ID, and export name.
    • First, the module, ID and export name are uniquely determined, and the corresponding configuration behind ischunkIds: "deterministic", moduleIds: "deterministic", mangleExports: "deterministic"
    • The module ID and module ID are 3-to-4-digit ids, and the export name is 2-digit ID
    • This setting is enabled by default, but can also be modified through the above configuration
  • Real content hash
    • In Webpack5, the actual hash of the file’s contents is used[contenthash]Instead of just using the internal structure of the file
    • This has a positive effect on long-term caches, especially if there are only comments and variable name changes in the code, and Webpack continues to use the previous cache instead of the new file content

Development support

  • The first is the semantics of Chunk IDs.
    • The new Chunk IDs use a new syntax to generate Chunk IDs. A Chunk ID is determined by the contents of the Chunk. So we don’t need it anymoreimport(/* webpackChunkName: "name" */ "module")To was debugging
    • But it could also expose sensitive chunks, if any, by modifying themchunkIds: "named"To modify this behavior
  • The second is Module Federation
    • This is a feature worth highlighting. Module federation allows multiple Webpack build artifacts to work together, aggregating multiple build artifacts at run time to look like one large build artifact.
    • For example, app_one and app_two use the shared["react", "react-dom","react-router-dom"]At the same time app_two exposes its Dialog to App_One
    • The problem of direct module dependency can be solved natively through module federation, especially in the microfront-end domain! At the same time, some of the base dependencies may be changed to external dependencies, which do not need to be introduced in local development. By avoiding the well-known problem of too deep node_modules, it is possible to achieve significant improvements in local development
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: "app_two_remote".      library: { type: "var".name: "app_two_remote" },
 filename: "remoteEntry.js". exposes: { ". / "Dialog:"./src/Dialog"  },  remotes: {  app_one: "app_one_remote". },  shared: ["react"."react-dom"."react-router-dom"]  }),  new HtmlWebpackPlugin({  template: "./public/index.html". chunks: ["main"]  })  ] }; Copy the code
  • Better Tree Shaking.
    • Nested tree – shaking. Webpack now tracks export links, which is better optimized for nested scenarios, such as in the following examplebIt doesn’t show up in production code.
// inner.js
export const a = 1;
export const b = 2;

// module.js
import * as inner from "./inner"; export { inner }  // user.js import * as module from "./module"; console.log(module.inner.a); Copy the code
  • Internal modules. Webpack 4 does not analyze the dependencies between import and export modules, Webpack5 doesoptimization.innerGraphRecord dependencies. In this example, onlytestThe method usessometing. Eventually, you can implement the markup of more unused exported items
import { something } from "./something";

function usingSomething() {
return something;
}
 export function test() { return usingSomething(); } Copy the code
  • Commondjs. Now Webpack supports not only tree Shaking for ES Modules, but modules with the CommonJS specification

Other features

  • New Web platform support. Native support for JSON Modules, Asset Modules, Native workers, asynchronous Modules, and more began in Webpack 5
  • Webpack will not only generate ES5 code, but also ES6 code
  • The minimum supported version of Node.js has been upgraded from 6 to 10

Early adopters can now follow the migration guide to upgrade their own Webpack, and out of caution, it is recommended to start with your own hands-on and background apps

The migration guide: https://github.com/webpack/changelog-v5/blob/master/MIGRATION%20GUIDE.md

summary

As you can see, Webpack5 has undergone a number of upgrades over the past two years, including better performance, stronger development capability support, and more native features. The impact of Webpack5 is not only this, Module Federation’s change of Module dependency and impact on the existing development mode are still under further observation. Expect Web development to get better and better.

More content welcome to pay attention to the public account “Advance front 101”