Webpack5

关于webpack5:小白上学之webpack5-第二章-webpack5的初入门

上一节实现nvm、nrm、node和npm的各项配置后，这一章就开始装置webpack5webpack5装置轻易找个地位新建文件夹，起名为：webpack5进入该文件夹，命令行输出: cd webpack5再次输出npm init或者npm init -y -y意思是一路yes查看文件夹, 发现多了一个名为package.json的文件，文件内容如下： { "name": "webpack5", "version": "1.0.0", "description": "study", "main": "index.js", "scripts": { "test": "test" // 此处无所谓是什么不必管它 }, "author": "qqf", "license": "ISC"}再次输出：npm install webpack@5 webpack-cli -D装置webpack和webpack-cli -D：--save-dev；开发环境须要应用到的工具，既构建后不会应用到的包-S：-save；生产环境须要应用到的工具，既构建后要应用到的包能够看到webpack.json内新减少了 "devDependencies"{ "webpack": "^5.82.1", "webpack-cli": "^5.1.1"}构建一个简略的前端我的项目工作一： html、js和css资源能够失常输入工作二：构建后的包能够在浏览器端失常运行在webpack5文件夹内创立文件夹src，并在src文件夹内创立文件index.js、index.css和index.html三个文件在index.html文件内输出 <!DOCTYPE html><html lang="zh-CN"><head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title></head><body> <h1>Hello 啊！树哥！<h1> <h2>方才里面人多，我给你跪下了...<h2></body></html>在index.js内输出 import './index.css'console.log('每天都要多学一点，卷死同行！')在index.css内输出 body {background-color: pink; // 粉粉嫩嫩少女心，难道你不爱？呕~}在根目录创立一个名为：webpack.config.js的文件在命令行输出: npm i html-webpack-plugin -D 装置此插件在webpack.config.js文件内输出: const HtmlWebpackPlugin = require('html-webpack-plugin')const path = require('path')module.exports = { entry: './src/index.js', plugins: [ new HtmlWebpackPlugin({ template: path.resolve(__dirname, './src/index.html'), }), ],}__dirname: 为node环境内获取以后文件地址固有变量path.resolve: 会把一个门路或门路片段的序列解析为一个绝对路径path.join:应用分隔符把全副给定的 path 片段连贯到一起，并规范化生成的门路再装置css-loader, 执行命令: npm i css-loader -D在package.json文件内找到，scripts属性，减少执行脚本命令:"scripts": { "build": "webpack"}在webpack.config.js文件内输出: ...

关于webpack5:Webpack5构建性能优化构建耗时从150s到60s再到10s-京东云技术团队

作者：京东科技牛志伟近期对Webpack5构建性能进行了优化，构建耗时从150s到60s再到10s，上面具体解说下优化过程。优化前现状1.历史我的项目基于Vue3 + Webpack5技术栈，其中webpack配置项由开发者本人保护（没有应用@vue/cli-service），并且做了环境拆散。 2.我的项目体量大概5000个modules左右，每次本地构建build时耗时约150s左右。优化细节环境拆散之前曾经设计了环境拆散，然而一些优化细节没有解决好： •根底配置文件：webpack.base.js，次要配置了根底的loader和plugin等 •本地开发配置文件：webpack.dev.js，次要配置了devServer和款式、图片资源loader等，并merge根底配置 •生产环境配置文件：webpack.prod.js，次要配置了款式、图片资源loader以及资源压缩和款式抽离等，并merge根底配置优化点： •热加载相干配置，从base移到dev配置中，生产环境中不须要热更新 new webpack.HotModuleReplacementPlugin()•dev配置中devtool类型抉择，inline-source-map批改为eval-cheap-module-source-map，map文件应用内联形式构建速度更快。 devtool: 'eval-cheap-module-source-map'•filename调整：js/[name].[fullhash].js去掉hash，本地开发环境启用热更新，不须要hash（生产环境须要hash刷新缓存） output: { filename: 'js/[name].js', path: path.resolve(__dirname, '../dist'), publicPath: '/',}长久化缓存base配置中开启长久化缓存（Webpack5新个性），首次构建耗时减少15%左右，然而二次构建耗时缩小90%左右 cache: { type: 'filesystem'}Loader相干优化•尽量减少loader，比方应用Asset modules（Webpack5新个性）替换url-loader、file-loader、raw-loader // 字体和小于8kb的图片{ test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/, type: 'asset', parser: { dataUrlCondition: { maxSize: 8 * 1024, }, }}// 图片资源{ test: /\.(png|svg|jpg|gif|cur)$/, type: 'asset/resource', exclude: [path.resolve(__dirname, '../../../assets/svg')],}•thread-loader耗时工作开启多线程 { test: /\.vue$/, use: ['thread-loader', 'vue-loader'],},{ test: /\.(t|j)s$/, exclude: /node_modules/, use: ['thread-loader', 'babel-loader'],},{ test: /\.(sa|sc|c)ss$/, use: ['thread-loader', 'style-loader', 'css-loader', 'sass-loader'},•esbuild-loader替换babel-loader（因为改变较大，没有尝试） ...

关于webpack5:Webpack5打包多入口的html项目

具体配置如下： const { resolve } = require("path");const HtmlWebpackPlugin = require("html-webpack-plugin");const CopyWebpackPlugin = require("copy-webpack-plugin");const MiniCssExtractPlugin = require("mini-css-extract-plugin");const CssMinimizerWebpackPlugin = require("css-minimizer-webpack-plugin");module.exports = { // 多入口 entry: { page1: ["./src/assets/js/page1.js"], page2: ["./src/assets/js/page2.js"], page3: ["./src/assets/js/page3.js"], }, output: { path: resolve(__dirname, "dist"), filename: "assets/js/[name][hash:10].js", }, module: { rules: [ { test: /\.css$/, use: [MiniCssExtractPlugin.loader, "css-loader"] }, { test: /\.(png|jpg|jpeg|gif|icon|webp)$/, type: "asset", parser: { dataUrlCondition: () => { return false; // 不在css中生产base64，全副打包为图片资源 }, }, generator: { filename: "assets/images/[name][hash:10][ext]", } }, { test: /\.(woff|woff2|svg|eot|ttf)\??.*$/, type: "asset/resource", generator: { filename: "assets/font/[name][hash:10][ext]", } }, { test: /\.(htm|html)$/i, use: ["html-withimg-loader"], // 解决html中标签引入的图片门路 } ], }, plugins: [ new CopyWebpackPlugin({ patterns: [ { from: "./src/assets/js/common", //想要复制的文件夹 to: "assets/js/common", //复制在哪个文件夹 }, { from: "./src/assets/images/icon", //想要复制的文件夹 to: "assets/images/icon", //复制在哪个文件夹 }, ], }), new HtmlWebpackPlugin({ template: "./src/index1.html", // webpack 模板的绝对或绝对路径 filename: "index1.html", // 将 HTML 写入到的文件 chunks: ["page1"], // 须要增加的js文件 hash: true, // 将css和js退出hash值 inject: "body", // 所有资源注入的地位 scriptLoading: "blocking", // script 标签加载形式 minify: { // collapseWhitespace: true, removeComments: true, }, }), new HtmlWebpackPlugin({ template: "./src/index2.html", filename: "index2.html", chunks: ["page2"], hash: true, inject: "body", scriptLoading: "blocking", minify: { // collapseWhitespace: true, removeComments: true, }, }), new HtmlWebpackPlugin({ template: "./src/index3.html", filename: "index3.html", chunks: ["page3"], hash: true, inject: "body", scriptLoading: "blocking", minify: { // collapseWhitespace: true, removeComments: true, }, }), new MiniCssExtractPlugin({ // chunkFilename: "[id].css", filename: "assets/css/style[hash:10].css", }), // 将css提取到独自的文件中 new CssMinimizerWebpackPlugin(), //对css进行压缩 ], // mode: "development", mode: "production",};打包前须要留神如下几点: ...

关于webpack5:图解webpack5热更新HRM

前置问题本地文件扭转，webpack是如何晓得并且触发编译的？浏览器是如何晓得本地代码从新编译，并且迅速申请了新生成的文件的？webpack本地服务器是如何告知浏览器？浏览器取得这些文件又是如何热更新的？热更新的流程是什么？前置知识点一. 代码扭转时主动编译的几种办法摘录自 webpack官网文档1.webpack's Watch Mode2.webpack-dev-server3.webpack-dev-middlewareWatch Mode{ "scripts": { "watch": "webpack --watch", "build": "webpack" }}命令行减少watch指令，当咱们扭转文件时，webpack会主动编译扭转的模块，然而咱们得手动刷新浏览器能力看到变动。 webpack-dev-serverwebpack.config.js const path = require('path');const HtmlWebpackPlugin = require('html-webpack-plugin');module.exports = { devServer: { static: './dist', }, optimization: { runtimeChunk: 'single',// 多入口时配置 }};package.json { "scripts": { "watch": "webpack --watch", "start": "webpack serve --open", "build": "webpack" }}webpack.config.js配置devServer属性，命令行减少webpack serve --open指令，当咱们扭转文件时，webpack会主动编译扭转的模块，并且主动刷新浏览器 webpack-dev-middlewarewebpack-dev-middleware内置于webpack-dev-server，次要是用于监测代码文件变动，解决文件编译等流程，咱们也能够将它独自拿进去进行其它场景的开发，比方联合express实现文件编译监听性能。server.js const express = require('express');const webpack = require('webpack');const webpackDevMiddleware = require('webpack-dev-middleware');const app = express();const config = require('./webpack.config.js');const compiler = webpack(config);// Tell express to use the webpack-dev-middleware and use the webpack.config.js// configuration file as a base.app.use( webpackDevMiddleware(compiler, { publicPath: config.output.publicPath, }));// Serve the files on port 3000.app.listen(3000, function () { console.log('Example app listening on port 3000!\n');});package.json ...

关于webpack5:全面敏捷模式下的微前端方案设计篇

这里是忽然怠惰的 Zhuo，继续更新文档中。本文只波及到 module-federation 微前端计划的设计层面分享，对于具体实现，能够参考写的简略例子；所有的设计图自取，如果对你有一些启发，请点个 star 背景团队从瀑布流模式转变为麻利模式，将整个我的项目团队划分为多个小组并行开发，多小组同时降级的分支解决和代码抵触之类的问题频繁呈现。于是接到了组内一个技术需要：《模块反对独自降级和部署》。目前，咱们开发和保护代码的现状：一个仓库蕴含了所有的业务组的前端代码只能一起打包出一个整包，也无奈独自部署后端已实现微服务的拆分如上所述，尽管个别场景通过 git 多分支治理能解决【独立开发】和【公布】的问题，然而一遇到【多团队同时公布】的场景就让人头疼了：须要拉上各个团队的负责人，重复确认当天是否失常上线上线分支排列组合（release-a、release-b、release-ab ）预防某一个团队突发问题不上线测试工作量减少：本来只有验收一个代码包，当初还要验证多个代码包性能（> 1）看一眼分支模型：既然提出了已有问题，为了解决这些问题，咱们意识到和后端一样将整个我的项目拆分成若干的子利用，将它们也变成微服务，不就能够解决目前的窘境了吗？自然而然咱们就想到了“微前端”的概念。有指标，就好发力了，咱们参考了业务优良计划，同时联合了本身理论状况，最终决定用webpack5 module federation 个性来进行微前端的实际与落地。需要剖析内部需要拆合成耦独自打包，独立部署不影响当初的用户体验外部需要不影响开发体验计划对原业务代码侵入性最低学习成本低对立技术栈前端灰度公布计划抉择计划：利用微服务化，诸如 qiankun2 存在性能问题，且沙箱逃逸问题难解决，放弃微件化：通过组合多个独立利用、组件来构建一个单体利用，例如 Module Federation 在接入第三方利用上存在的问题比拟大，然而对于咱们想要达到【独立降级】的成果来说，此短板能够承受联合 Web Components 构建，例如 micro-app 在解决沙箱的性能问题和逃逸问题上尽管比计划1更优良，但这两个问题呈现还是难解决，且目前官网保护的频率及未有稳固版本，放弃MPA+路由散发相当将本来的一个零碎拆成多个零碎，体验上无奈承受，放弃MPA + iframe iframe 在性能和用户体验上的问题也是无奈承受，放弃纯 Web Component 进行构建利用须要用一个新的根底计划将整个我的项目的代码重构，工作量上无奈承受，放弃最终采纳计划2：module federation。微前端实际通过计划的剖析以及我的项目理论状况的梳理，咱们确定了微前端的整体计划，输入组件图，如下图所示：能够看到，整个计划非常简单：依照开发小组进行路由级别的拆分，整个零碎可分为两个局部：基座利用：用于治理子利用的路由切换、注册子利用的路由和全局 Store 层、提供全局库和复用层子利用：用于开发子利用业务代码，一个子利用对应一个开发小组，并且治理本人的路由、语言包、埋点、Store基座利用和子利用分割起来的桥梁则是入口文件：remoteEntry.js。这能够让基座利用精确地发现子利用资源的门路从而进行加载。因为依赖了remoteEntry.js进行关联，所以这个文件不会加 hash 后缀，这就要求对该命名的文件全副设置协商缓存，不再是强缓存。微前端下的架构变动在整个计划的革新之后，咱们的我的项目整体的架构变成了如下图展现的样子：前端侧的代码依照小组个性拆分成若干个子利用：每个子利用只领有本人相干的代码，基座利用能够看成比拟非凡的子利用，它提供工程能力，最好不要有业务代码将利用代码划分到 packages/apps文件下，通过 monorepo + pnpm 进行治理依赖所有的文件夹进行独自的打包构建，搭配 Docker + Kubernetes 构建成独自的容器（红色局部内所有的子利用都是独自的容器）变成真正的微服务通过 ingressroute + nginx 加载不同容器之间的子利用资源以上的变动，让拆分进去的子利用可能独立开发 - 保护 - 公布之外，还使得咱们前端利用降级时的灰度 - 部署 - 回滚操作变得更加简略、疾速。 ...

关于webpack5:webpack5学习

webpack5学习webpack.config.js配置 entry入口文件配置，webpack依据该配置文件进行打包 module.exports={ ... // 入口文件，从哪个文件开始打包 entry: "./src/index.js", ...}output打包后的输入地位 const {resolve}=require("path")module.exports={ output: { // 打包后的文件名字 filename: "build.js", // 打包的绝对路径 path: resolve(__dirname, "build"), },}loader把浏览器不意识的文件翻译成浏览器可能意识的文件，例如将less文件翻译成css文件等等解决css的loader npm i css-loader style-loader module.exports={ ... //装置css-loader style-loader module: { rules: [ { // 匹配哪些文件，通常是用正则表达式 test: /\.css$/, // use的执行程序是从右到左，从下到上 use: [ // 创立style标签，将js中的款式插入到style外面，而后将style外面的款式插入到head标签当中 "style-loader", // 将css解决成commonjs模块，外面的内容是款式字符串。 "css-loader", ], }, ], }, ... }2.解决less的loader npm i less less-loadermodule.exports={ ... // loaders配置 module: { rules: [ // 解决less文件，不同的文件要用不同的loader { test: /\.less$/, use: [ "style-loader", "css-loader", // 将less文件翻译成css文件 "less-loader", ], }, ], }, ...}3.解决图片资源 ...

关于webpack5:webpack5持久化缓存

根本介绍长久化缓存是 webpack5 所带来的十分弱小的个性之一。一句话概括就是构建后果长久化缓存到本地的磁盘，二次构建(非 watch 模块)间接利用磁盘缓存的后果从而跳过构建过程当中的 resolve、build 等耗时的流程，从而大大晋升编译构建的效率。长久化缓存次要解决的就是优化编译流程，缩小编译耗时的问题，通过全新的缓存零碎的设计使得整个构建流程更加的高效和平安。在此之前官网或者社区也有不少解决编译耗时，进步编译效率的计划。例如官网提供的 cache-loader，可将上一个 loader 解决的后果缓存到磁盘上，下一次在走这个流程的时候(pitch)根据肯定的规定来应用缓存内容从而跳过前面 loader 的解决。不过 cache-loader 也仅仅能笼罩到经由 loader 解决后的文件内容，缓存内容的范畴比拟受限，此外就是 cache-loader 缓存是在构建流程当中进行的，缓存数据的过程也是有一些性能开销的，会影响整个的编译构建速度，所以倡议是搭配译耗时较长的 loader 一起应用。另外就是 cache-loader 是通过比照文件 metadata 的 timestamps，这种缓存生效策略不是十分的平安，具体见我之前遇到的case。此外还有 babel-loader、eslint-loader 内置的缓存性能，DLL 等。外围的目标就是曾经解决过的内容不须要再从新走一遍原有的流程。这些计划都能解决肯定场景下的编译效率问题。根本应用长久化缓存是开箱即用的一个性能，然而默认不开启。为什么 webpack 没有将这个性能默认开启呢？这个其实也在长久化文档中有做阐明：webpack 将(反)序列化数据的流程内置并做到的开箱即用，然而对于我的项目的使用者而言是须要充沛理解长久化缓存的一些根本配置和策略，来确保在理论开发环节编译构建的安全性(缓存生效策略)。先看下根本的配置规定 cache 应用： // webpack.config.jsmodule.exports = { cache: { // 开启长久化缓存 type: 'fileSystem', buildDependencies: { config: [__filename] } }}在 cache 字段下实现无关长久化缓存的根本配置，当 type 为 fileSystem 时开启长久化缓存的能力(watch 模式下是分级缓存配合应用)，另外须要特地留神的是 buildDependencies 的配置，这个配置和整个构建流程的安全性无关。常见于和我的项目相干的一些配置信息，例如你是应用 @vue/cli 进行开发的我的项目，那么 vue.config.js 就须要作为我的项目的 buildDependencies，此外 webpack 在外部解决流程当中将所有的 loader 也作为了 buildDependenceis，一旦 buildDependencies 产生了变更，那么在编译流程的启动阶段便会导致整个缓存生效，进而走一遍新的构建流程。 ...