缩窄route范围来提速本地打包的尝试

2024-06-15 16:28

本文主要是介绍缩窄route范围来提速本地打包的尝试,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

  • 为什么要缩窄route范围
  • 缩窄route的方式
  • 意外触发的重复构建
  • 重复构建的原因
  • 解决方案

为什么要缩窄route范围

对于一些大单页,单个router-view中可能包含上百个页面。但是开发的时候其实并不需要那么多调试那么多页面。
因此,为了节省不必要的打包和热更新时间,可以对route进行缩窄

缩窄route的方式

笔者这里以webpack-plugin的方式去做构建时的route文件变更,plugin逻辑大致如下:

// 在 environment 阶段去做文件覆写
class LimitRoutePlugin {apply(compiler) {const absoluteFilePath ='/Users/xxxxxx/route.ts';compiler.hooks.environment.tap('ModifyFilePlugin', () => {try {const data = fs.readFileSync(absoluteFilePath, 'utf-8');this.originalContent = data;const modifiedContent = modifyContent(data);fs.writeFileSync(absoluteFilePath, modifiedContent, 'utf-8');} catch (err) {console.error('Error modifying file before compilation:', err);}});}

意外触发的重复构建

在这里插入图片描述
按预期,笔者使用了同步语句做文件覆盖,webpack的watch不可能会监听到多余的文件变更行为。但是事实就是,用了LimitRoutePlugin之后,触发了重新构建。

好吧,只能调试webpack的watcher逻辑,看下内部到底干了什么,竟能监听到生命周期之前的文件变更行为

重复构建的原因

在这里插入图片描述
在这里插入图片描述

位于watchpack/lib/DirectoryWatcher.js 96行位置,webpack做了文件变更的初始化。注意此处有一个FS_ACCURACY,其值为1000。而在fileChange的判断中,FS_ACCURACY会参与计算,这个buffer变量也就导致了webpack能监听到生命周期之前的文件变更行为。

可能有些难懂,画个时间轴就简单了:

我们假设plugin生效的时间点为x,webpack监听到文件改动的事件点为y。
更具fileChange的判断逻辑,只要x与y的差值小于1000,webpack就能监听到先前的文件变更,触发额外的重新构建。

解决方案

…有空再写

这篇关于缩窄route范围来提速本地打包的尝试的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1063973

相关文章

springboot3打包成war包,用tomcat8启动

1、在pom中,将打包类型改为war <packaging>war</packaging> 2、pom中排除SpringBoot内置的Tomcat容器并添加Tomcat依赖,用于编译和测试,         *依赖时一定设置 scope 为 provided (相当于 tomcat 依赖只在本地运行和测试的时候有效,         打包的时候会排除这个依赖)<scope>provided

本地如何快速启动静态服务器

本地快速启动静态服务器 有许多第三方库可以帮助你快速启动一个静态服务器,甚至无需编写代码。通过命令行运行这些库后,它们会自动启动一个服务器并打开指定端口,展示当前目录下的文件内容: 电脑得提前安装NodeJS 1、http-server http-server 是一个轻量级的命令行工具,允许你快速启动一个静态文件服务器。 安装 npm install -g http-server

android6/7 system打包脚本

1.android5打包system就是网站上常见的制作ROM必备的解包打包system脚本 指令如下:mkuserimg.sh -s out/target/product/$TARGET_PRODUCT/system out/target/product/$TARGET_PRODUCT/obj/PACKAGING/systemimage_intermediates/system.img

android打包解包boot.img,system.img

原帖地址:http://www.52pojie.cn/thread-488025-1-1.html 转载Mark一下,日后研究 最近工作需要对boot.img,system.img进行破解。顺便将心得分享一下。 我的工作环境是在linux下的。所以工具都是针对linux的。 boot.img破解相关工具: 1、split_boot    perl脚本 2、boot_i

MTK Android P/Q system/vendor/super快速打包

一、Android 新版本默认开启了动态分区,把system vendor  product等分区打包成一个super分区。这对于我们使用替换分区的方法来排查问题不是很方便,直接替换一个super也不知道到底是哪个部分导致的。所以我们需要自己制作super.img来缩小范围。下面讲讲如何快速生成system、vendor、super,以及vbmeta(校验image,不匹配可能会导致不开机) 二

MTK AndroidP/Q快速打包ramdisk

一、Android P/Q ramdisk与老版本的差异 Android老版本的ramdisk是out下的root/ramdisk打包而来,里面包含了init  /sbin  init.rc   default.prop等文件。是一个完整的ramdisk Android新版本ramdisk分为了out 下的ramdisk目录和root目录,init ,init.rc等文件大部分都放到了syst

Android P/Q MTK平台无依赖打包boot.img

背景:        有时排查版本问题,需要用到替换img的方式来查找问题出现在哪个img,若出现在bootimg,那到底是kernel、DTB 还是ramdisk。此时就需要单独替换其中一个的方式来打包,之前直接make bootimage-nodeps就可以了,但现在发现执行这个命令无效了。下面就分析下新版本如何找到正确的打包命令。 一、找到编译boot的命令 之前Android编译lo

【20240907问题记录(未解决)】Conda环境问题:SSH与本地环境变量不一致

Conda 允许用户在同一系统上创建多个独立的Python环境。然而,最近遇到了一个奇怪的问题:通过SSH连接到远程Ubuntu机器时,Conda环境变量的行为与本地机器不一致。以下是具体遇到的问题: 1. 问题描述 在本地Ubuntu机器上,我的conda的python版本是3.6,而pip版本可以通过命令 pip --version 查看,显示为: pip 21.3.1 from /ho

Qt5项目打包

笔者本来想尝试将项目在Windows环境和Linux环境下都打包发布,但是Linux环境下各种办法都尝试了,还是有点问题,先总结记录下吧。 参考文章:https://blog.csdn.net/windsnow1/article/details/78004265 http://www.cnblogs.com/lvdongjie/p/7250547.html http://doc.qt.io/ar

我成功在本地打开了Cesium啦!

1首先下载Node.js,我是跟着这篇下载的,https://zhuanlan.zhihu.com/p/77594251,不过这后面的我没弄对Cesium环境配置也没影响。 另外:我看其他推文说,在终端写node -v和npm-v查node和npm的版本可以检测node和npm是否下载成功。 2然后我在CesiumB站官号看的教学视频,跟着下载Cesium源代码。 Cesium基础入门1-零