Vue upgrade webpack5
August more text second play, start! 🍦
Webpack5 has been out for almost a year, and there are a lot of new features to try out. How can we, as technology enthusiasts, stand still? 🐶, today we’ll learn about building projects and new features with WebPack5.
To upgrade the vue – cli
Webpack5 is easy to upgrade in vUE projects. You can upgrade the local VUE -CLI to 5.0.0, but note that this is a beta version, please use it with caution in online environments.
- Upgrade the vue – cli 📃
First, install the latest Vue CLI globally:
npm install -g @vue/cli@next#
OR
yarn global add @vue/cli@next
Copy the code
- Upgrade all plug-ins
Upgrade All Plugins at Once
vue upgrade --next
Copy the code
- check
After the upgrade is complete, view package.json, as shown in the figure, indicating that the upgrade is successful. The example project is a new project, and there is no NPM package incompatibility. If you upgrade an old project, you will encounter many compatibility problems. Please go to the next stepVue Upgrade webPack5 website view.
Webpack5 new features
With the official introduction to WebPack, version V5 has the following major additions
Obsolete features removed
-
The first is to remove the Warming feature in Webpack4.
-
Second, IgnorePlugin and BannerPlugin must now pass a parameter, which can be Object, String, or Function. The require.include syntax is deprecated and Warming is present when used. , of course, this behavior can be Rule. The parser. RequireInclude to change the syntax to charges, deprecated or disabled.
-
In addition, eliminate the automatic Node.js Polyfills. In the beginning, the main goal of Webpack was to make Node.js modules work in the browser, but as the module pattern changed and more and more modules were used only in the browser, polyfilling some Node modules (such as Crypto) would inevitably increase the packaging volume. This automatic behavior was removed after Webpack5.
The cache for a long time
Webpack5’s long-term caches are supposed to deal with the following issues:
- Code hot update speed is fast
- The code runs slowly
- Code packaging build is slow
The reason for this is that WebPack4’s cache is only in memory, which is lost when the WebPack program is rebuilt, resulting in slow runtime and packaging. Webpack 5’s long cache is a solution to the problem of webPack programs running slow due to cache loss. Currently, WebPack5 provides a set of persistence abstractions and provides several implementations:
IdleFileCachePlugin
: persists to the local diskMemoryCachePlugin
: Persists to memory
Depending on the Webpack runtime environment, the MemoryCachePlugin will still be used during dev development and the IdleFileCachePlugin will be used during build.
Webpack5 unified the persistent cache solution directly from the internal core code level, effectively reducing the complexity of cache configuration. In addition, since all modules that are processed by WebPack are cached, our NPM run start/build is much faster than that of cache-Loader, and the DLL can be retired.
DLL is required for Webpack4 because cache-Loader cannot overwrite all modules and can only cache individual modules processed by Loader. Generic libraries cannot be processed by the cache-loader, so they can only be precompiled using DLLS.
In fact, Webpack5’s built-in caching scheme is better than cache-Loader in both performance and security:
- Performance: Since all modules processed by WebPack are cached, the cache coverage is much higher
- Security: Because cache-Loader uses mtime-based cache validation, the cache is often invalid in CI environments, but Webpack5 uses eTAG-based cache validation to solve this problem.
Module Federation
This is translated as module federation, which sounds a little strange. But it’s probably one of the most striking features of webpack5, which is the ability to actually share modules between different applications.
Let’s say we have application A and application B, and we want application B to use a component of application A. At this point, the first idea might be to build a CV, but later maintenance would be very difficult, and real-time synchronization of component updates would not be guaranteed. Module federation solves this problem for us. The detailed usage will be explained in the next article, webPack5 – Module Federation Implementation Micro Front End. Hope you pay close attention to it
The Better TreeShaking
There are two main points of tree shaking optimization:
- nested
Webpack now tracks export links, better optimized for nested scenarios. In the example code below, we end up using only webpack_five and webpack_four will not appear in the final package.
// inner.js`
export const webpack_four = 4
export const webpack_five = 5
// module.js
import * as inner from "./inner"
export { inner }
// user.js`
import * as module from "./module"
console.log(module.inner.webpack_five)
Copy the code
- Internal module
Webpack 4 does not analyze dependencies between import and export modules. Webpack5 records dependencies through optimization. InnerGraph. In the example code below, only the webpack_cookie method uses egg. You can eventually tag more exports that are not in use.
import { egg } from "./egg"
function eatingEgg() {
return egg
}
export function webpack_cookie() {
return eatingEgg()
}
Copy the code
Other features
- Named chunk IDs Named chunk IDs
- Compilers
- Config changes
- other
- webpack5
The last
The end of this article, hope to help you 😉