找到
5
篇与
NodeJs
相关的结果
-
删除 node_modules 目录太慢了？教你快速删除 前言 大家好，我是易航，用最通俗易懂的话讲最难的知识点是我的座右铭，基础是进阶的前提是我的初心~ 在开发过程中，node_modules 文件夹常常会因为存放了大量的依赖包而变得庞大，尤其是在大型项目中。虽然 node_modules 是 Node.js 项目中不可或缺的一部分，但在一些特定的情况下，比如清理无用依赖或是重新安装依赖时，删除 node_modules 文件夹是一个常见的操作。然而，手动删除这么大的文件夹往往是一个耗时且效率低下的过程。对于开发者而言，如何快速有效地删除 node_modules 成为了一个常见的痛点。 这时，rimraf 工具就显得尤为重要，它可以替代rm -rf命令来递归删除文件夹，并且相较于手动删除，它提供了更高效的方式。 一、什么是 rimraf？ rimraf 是一个 Node.js 库，用于递归地删除文件和目录，特别适用于删除 node_modules 这样的庞大文件夹。rimraf 在删除文件和文件夹时，采用了优化过的实现，特别能够提高大文件夹删除的效率。 与操作系统自带的 rm -rf 命令相比，rimraf 通过减少系统调用、避免进程挂起等方式，能够加快删除过程，尤其在 Windows 平台上表现尤为突出，因为 Windows 本身对于删除大量文件的支持不如类 Unix 系统。 二、为什么手动删除 node_modules 这么慢？ 在大型 Node.js 项目中，node_modules 文件夹可能包含上万个文件和子文件夹。由于 node_modules 文件夹结构的复杂性和深度，手动删除该文件夹需要操作系统一次性处理大量的文件删除操作。在这种情况下，操作系统的文件系统（如 macOS 的 HFS+ 或 Windows 的 NTFS）可能会出现延迟，导致删除过程非常缓慢。 图片 1. 操作系统的文件系统限制 操作系统的文件系统并没有针对大规模删除优化。例如，当你使用文件资源管理器删除文件时，它实际上是逐一标记每个文件为删除状态，并且还会消耗大量的资源来更新文件索引。这对于 node_modules 这种成千上万个文件的文件夹来说，执行起来非常低效。 2. 文件系统缓存和索引 文件操作系统通常会保持一定的缓存和索引记录，以便加速文件的读写和删除过程。然而，当需要删除大量文件时，这些缓存和索引会成为瓶颈，导致删除变得缓慢。 三、如何使用 rimraf 加速删除过程？ rimraf 是一个专为递归删除大文件夹设计的工具，它通过优化删除过程中的一些细节，避免了文件系统缓存和索引的限制，使得删除过程更加高效。使用 rimraf 删除 node_modules 的步骤非常简单，以下是详细的操作流程。 1. 安装 rimraf 首先，我们需要在项目中安装 rimraf。可以通过 npm 或 yarn 来安装它。打开你的命令行，进入到你的项目目录下，执行以下命令： npm install rimraf --save-dev或者使用 yarn： yarn add rimraf --dev2. 在命令行中使用 rimraf 安装完成后，你可以在命令行中直接使用 rimraf 来删除 node_modules 文件夹。以下是使用 rimraf 删除 node_modules 的命令： npx rimraf node_modules3. 在 package.json 中配置脚本 为了简化操作，可以将删除命令添加到 package.json 中的 scripts 部分： { "scripts": { "clean": "rimraf node_modules" } }然后运行： npm run clean4. 使用 rimraf 加速其他删除操作 除了删除 node_modules，rimraf 还可以删除其他大文件夹： npx rimraf build四、rimraf 的优势 跨平台兼容：支持 Linux、macOS 和 Windows。 高效删除：针对大规模文件删除优化，速度显著提升。 易于使用：通过命令行或脚本配置即可快速操作。 与包管理工具集成：无缝配合 npm、yarn 使用。 五、总结 rimraf 是一个轻量级、高效且跨平台的工具，特别适合快速删除 node_modules 等大型文件夹。通过优化删除流程，它能显著提升开发效率，尤其是在 Windows 系统上表现突出。如果你还在手动删除 node_modules，不妨尝试使用 rimraf 来简化工作流程。 结语 我是易航，待过多种类型公司的前端开发者，始终坚持用通俗易懂的方式分享技术知识。欢迎关注我的博客「易航博客」获取更多前端干货！
-
pnpm 的崛起：如何降维打击 npm 和 yarn 前言 今天研究了一下 pnpm 的机制，发现它确实很强大，甚至可以说对 yarn 和 npm 形成了降维打击 我们从包管理工具的发展历史，一起看下到底好在哪里？ npm2 在 npm 3.0 版本之前，项目的 node_modules 会呈现出嵌套结构，也就是说，我安装的依赖、依赖的依赖、依赖的依赖的依赖...，都是递归嵌套的 node_modules ├─ express │ ├─ index.js │ ├─ package.json │ └─ node_modules │ ├─ accepts │ │ ├─ index.js │ │ ├─ package.json │ │ └─ node_modules │ │ ├─ mime-types | | | └─ node_modules | | | └─ mime-db | │ └─ negotiator │ ├─ array-flatten │ ├─ ... │ └─ ... └─ A ├─ index.js ├─ package.json └─ node_modules └─ accepts ├─ index.js ├─ package.json └─ node_modules ├─ mime-types | └─ node_modules | └─ mime-db └─ negotiator设计缺陷 这种嵌套依赖树的设计确实存在几个严重的问题 「路径过长问题：」 由于包的嵌套结构 ， node_modules 的目录结构可能会变得非常深，甚至可能会超出系统路径长度上限 ，毕竟 windows 系统的文件路径默认最多支持 256 个字符 「磁盘空间浪费：」 多个包之间难免会有公共的依赖，公共依赖会被多次安装在不同的包目录下，导致磁盘空间被大量浪费 。比如上面 express 和 A 都依赖了 accepts，它就被安装了两次 「安装速度慢」：由于依赖包之间的嵌套结构，npm 在安装包时需要多次处理和下载相同的包，导致安装速度变慢，尤其是在依赖关系复杂的项目中 当时 npm 还没解决这些问题， 社区便推出了新的解决方案 ，就是 yarn。它引入了一种新的依赖管理方式——「扁平化依赖。」 看到 yarn 的成功，npm 在 3.0 版本中也引入了类似的扁平化依赖结构 yarn 「yarn 的主要改进之一就是通过扁平化依赖结构来解决嵌套依赖树的问题」 具体来说铺平，yarn 尽量将所有依赖包安装在项目的顶层 node_modules 目录下，而不是嵌套在各自的 node_modules 目录中。 这样一来，减少了目录的深度，避免了路径过长的问题 ，也尽可能避免了依赖被多次重复安装的问题 图片 我们可以在 yarn-example 看到整个目录，全部铺平在了顶层 node_modules 目录下，展开下面的包大部分是没有二层 node_modules 的 然而，有些依赖包还是会在自己的目录下有一个 node_modules 文件夹，出现嵌套的情况，例如 yarn-example 下的http-errors 依赖包就有自己的 node_modules，原因是： 当一个项目的多个依赖包需要同一个库的不同版本时，「yarn 只能将一个版本的库提升到顶层」 「node_modules」 「目录中。」 对于需要「这个库其他版本」的依赖，yarn 仍然需要在这些依赖包的目录下创建一个嵌套的 node_modules 来存放不同版本的包 比如，包 A 依赖于 lodash@4.0.0，而包 B 依赖于 lodash@3.0.0。由于这两个版本的 lodash 不能合并，yarn 会将 lodash@4.0.0 提升到顶层 node_modules，而 lodash@3.0.0 则被嵌套在包 B 的 node_modules 目录下。 幽灵依赖 「虽然 yarn 和 npm 都采用了扁平化的方案来解决依赖嵌套的问题，但这种方案本身也有一些缺陷，其中幽灵依赖是一个主要问题。」 幽灵依赖，也就是你明明没有在 package.json 文件中声明的依赖项，但在项目代码里却可以 require 进来 这个也很容易理解，因为依赖的依赖被扁平化安装在顶层 node_modules 中，所以我们能访问到依赖的依赖 但是这样是有隐患的，因为没有显式依赖，未来某个时候这些包可能会因为某些原因消失（例如新版本库不再引用这个包了，然后我们更新了库），就会引发代码运行错误 浪费磁盘空间 「而且还有一个问题，就是上面提到的依赖包有多个版本的时候，只会提升一个，那其余版本的包不还是复制了很多次么，依然有浪费磁盘空间的问题」 那社区有没有解决这俩问题的思路呢？pnpm 就是其中最成功的一个 pnpm pnpm 通过「全局存储和符号链接机制」从根源上解决了依赖重复安装和路径长度问题，同时也避免了扁平化依赖结构带来的幽灵依赖问题 pnpm 的优势概括来说就是“快、准、狠”： 快：安装速度快 准：安装过的依赖会准确复用缓存，甚至包版本升级带来的变化都只 diff，绝不浪费一点空间 狠：直接废掉了幽灵依赖 执行 npm add express，我们可以在 pnpm-example 看到整个目录，由于只安装了 express，那 node_modules 下就只有 express 图片 那么所有的（次级）依赖去哪了呢？binggo，在node_modules/.pnpm/目录下，.pnpm/ 以平铺的形式储存着所有的包 图片 三层寻址 所有 npm 包都安装在全局目录 ~/.pnpm-store/v3/files 下，同一版本的包仅存储一份内容，甚至不同版本的包也仅存储 diff 内容。 顶层 node_modules 下有 .pnpm 目录以打平结构管理每个版本包的源码内容，以硬链接方式指向 pnpm-store 中的文件地址。 每个项目 node_modules 下安装的包以软链接方式将内容指向 node_modules/.pnpm 中的包。所以每个包的寻找都要经过三层结构：node_modules/package-a > 软链接 node_modules/.pnpm/package-a@1.0.0/node_modules/package-a > 硬链接 ~/.pnpm-store/v3/files/00/xxxxxx。 这就是 pnpm 的实现原理。官方给了一张原理图，可以搭配食用 图片 前面说过，npm 包都被安装在全局 pnpm store ，默认情况下，会创建多个存储（每个驱动器（盘符）一个），并在项目所在盘符的根目录 所以，同一个盘符下的不同项目，都可以共用同一个全局 pnpm store，绝绝子啊👏，大大节省了磁盘空间，提高了安装速度 图片 软硬链接 也就是说，所有的依赖都是从全局 store 硬连接到了 node_modules/.pnpm 下，然后之间通过软链接来相互依赖。 那么，这里的软连接、硬链接到底是什么东西？ 硬链接是指向磁盘上原始文件所在的同一位置 （直接指向相同的数据块） 软连接可以理解为新建一个文件，它包含一个指向另一个文件或目录的路径 （指向目标路径） 图片 总结 「npm2 的嵌套结构」：每个依赖项都会有自己的 node_modules 目录，导致了依赖被重复安装，严重浪费了磁盘空间💣；在依赖层级比较深的项目中，甚至会超出 windows 系统的文件路径长度💣 「npm3+ 和 Yarn 的扁平化策略：」 尽量将所有依赖包安装在项目的顶层 node_modules 目录下，解决了 npm2 嵌套依赖的问题。但是该方案有一个重大缺陷就是“幽灵依赖”💣；而且依赖包有多个版本时，只会提升一个，那其余版本依然会被重复安装，还是有浪费磁盘空间的问题💣 「pnpm全局存储和符号链接机制：」 结合软硬链和三层寻址，解决了依赖被重复安装的问题，更加变态的是，同一盘符下的不同项目都可以共用一个全局 pnpm store。节省了磁盘空间，并且根本不存在“幽灵依赖”，安装速度还贼快💪💪💪
-
npm最新国内镜像源设置 国内源 淘宝：https://registry.npmmirror.com/ 腾讯云：https://mirrors.cloud.tencent.com/npm/ CNPM：https://r.cnpmjs.org/ 设置 #查询当前使用的镜像源 npm get registry #设置为淘宝镜像源 npm config set registry https://registry.npmmirror.com/ #验证设置 npm get registry #还原为官方源 npm config set registry https://registry.npmjs.org/
-
一款功能丰富、界面美观的OA办公系统 介绍 OA-System Vue 开发的OA系统 具有工作流动态审批、加签、会签等工作流功能 具有文档预览、图片预览等功能 具有博客编写、预览、查看、搜索等功能 具有社区、问答等功能 具有OA系统常用功能 具有在线网盘等功能 支持审批流程、自由流程，审批日志，我的待办，我的已办，行政公告，Office文档预览，文档转PDF，图片压缩。 功能一览 具有工作流动态审批、加签、会签等工作流功能，可以对工作流程的审批业务进行评论/讨论 具有文档预览、图片预览等功能 具有博客编写、预览、查看、搜索等功能 具有社区、问答等功能 具有OA系统常用功能 具有在线网盘等功能 具有OA的移动端应用 工作流引擎完全手写且开源，可以类似钉钉/飞书那样，动态选择审批人员。 项目截图 图片 图片 图片 图片 图片 图片 图片 图片 图片 源码下载 隐藏内容，请前往内页查看详情
-
一键将网页打包成很小的桌面 App，30.1K Star，更小，更轻量 大家好，我是易航 今天给大家推荐的开源项目是：Pake，它可以将网页打包成桌面应用，非常适合想把网页应用“本地化”的场景！我们从以下几个方面简单介绍一下这个项目，方便你快速了解。 图片 Pake软件简介 Pake 的主要功能是通过 Webview 将网页打包成本地桌面应用。这意味着你可以把常用的网页，比如 Baidu、小红书 或者自定义的 Web 应用，做成独立的桌面应用程序，免去了打开浏览器标签页的麻烦。它支持 Windows、macOS 和 Linux，覆盖面广，适用性强。 项目地址： 隐藏内容，请前往内页查看详情 Pake核心特征 🎐 相比传统的 Electron 套壳打包，要小将近 20 倍，5M 上下。 🚀 Pake 的底层使用的 Rust Tauri 框架，性能体验较 JS 框架要轻快不少，内存小很多。 📦 不是单纯打包，实现了快捷键的透传、沉浸式的窗口、拖动、样式改写、去广告、产品的极简风格定制。 👻 只是一个很简单的小玩具，用 Tauri 替代之前套壳网页打包的老思路，其实 PWA 也很好。 Pake安装使用 Pake针对不同用户给出了不同的安装使用方案。 1.小白用户 Pake已经把常见的网站已经打包好了，直接下载使用即可。预打包的网站有 微信读书 Twitter ChatGPT Poe YouTube LiZhi 小红书 无vpn用户，可以从123网盘下载：隐藏内容，请前往内页查看详情 图片 2.开发用户 Pake提供了 「命令行一键打包」功能，对 Mac 比较友好，Windows / Linux 需折腾下 环境配置。 图片 同时，Pake还提供了命令行工具，**可以更快捷方便地一键自定义打你需要的包** # 使用 npm 进行安装 npm install -g pake-cli # 命令使用 pake url [OPTIONS]... # 随便玩玩，首次由于安装环境会有些慢，后面就快了 pake https://weekly.tw93.fun --name Weekly --hide-title-bar3.折腾用户 假如你前端和 Rust 都会，那可试试下面的 「定制开发」，可深度二次开发定制你的功能。 开始前请确保电脑已经安装了 Rust >=1.63 和 Node >=16 如 16.18.1 的环境，此外需参考 Tauri 文档 快速配置好环境才可以开始使用，假如你太不懂，使用上面的命令行打包会更加合适。 # 安装依赖 npm i # 本地开发[右键可打开调试模式] npm run dev # 打包应用 npm run build写在最后 Pake 通过高效、简洁的方式将网页打包为桌面应用，适合个人和开发者的多种需求。它的轻量化、跨平台支持、灵活配置和性能优势让它成为了构建网页桌面应用的理想工具。
