给 npm install 做一次大扫除：我如何干掉 deprecated inflight 和 glob 警告

原创已于 2025-10-09 21:51:32 修改 · 1.1k 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#npm #arcgis #前端

于 2025-10-09 21:12:53 首次发布

Vue 3 + Vite + Element Plus 专栏收录该内容

14 篇文章

订阅专栏

🧹 给 `npm install` 做一次大扫除：我如何干掉 `deprecated inflight` 和 `glob` 警告

嘿，各位前端开发者！

你是否也曾遇到过这样的场景：克隆一个新项目，或者删掉 node_modules 重新 npm install 后，终端里赫然出现了几行黄色的 deprecated 警告？

npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory...
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported

虽然项目也能跑起来，但这些警告就像房间角落里的蜘蛛网，不清理掉总觉得心里不舒服。而且，leaks memory (内存泄漏) 这种字眼，更是让有代码洁癖的我们无法容忍！😤

今天，我就带大家完整复盘一次我如何像侦探一样，一步步揪出这些“老古董”依赖的幕后黑手，并最终让我的 npm install 恢复清爽的全过程。

🤔 第一站：警告从何而来？—— “依赖的依赖”

首先，我检查了我的 package.json 文件，从头到尾看了一遍，根本没有发现 inflight 或 glob 这两个包。

这就引出了 npm (Node Package Manager, Node包管理器) 依赖管理的第一个核心概念：间接依赖 (Indirect Dependencies)。

我们项目中 package.json 里列出的，只是直接依赖。而这些直接依赖，又会依赖其他的包，一层套一层，形成一个巨大的依赖树。inflight 和 glob 正是这棵树深处的某个“老旧”的枝丫。

我们的任务，就是找到是哪个“主干”（直接依赖）还连着这个“老枝丫”。

🕵️‍♂️ 第二站：`npm ls` —— 我的依赖侦探镜

npm 提供了一个超级有用的命令 ls，它可以帮我们查看一个包到底是被谁所依赖的。

我决定先从 glob 这个警告下手，因为它看起来更像是一个功能性的包。

npm ls glob

终端立刻给出了决定性的线索：

admin-vue3@0.0.0 /Users/dgq/Documents/admin/admin-vue3
└─┬ style-resources-loader@1.5.0
  └── glob@7.2.3

破案了！ 🕵️‍♂️

这个输出清晰地告诉我们：

是 style-resources-loader 这个包，在其 1.5.0 版本中，依赖了旧的、已经被弃用的 glob@7.2.3。
而 glob@7.2.3 又很可能依赖了那个更古老的 inflight 包。

“元凶”找到了，就是 style-resources-loader！

🛠️ 第三站：如何处置“元凶”？—— 升级还是替代？

现在我们有两种选择：

升级它：看看 style-resources-loader 有没有发布新版本来解决这个问题。
干掉它：思考一下，在我的项目中，我真的还需要这个包吗？

我先执行了 npm view style-resources-loader version，发现 1.5.0 已经是它的最后一个版本了。这说明这个包的作者很可能已经停止维护了。指望升级是没戏了。

于是，我转向了第二个思路。style-resources-loader 的作用是在 Webpack 项目中自动注入全局的Sass/Less变量。但是，我的项目是一个现代化的 Vite 项目！

我立刻检查了我的 vite.config.ts 文件，发现里面已经有了这段代码：

// vite.config.ts
css: {
  preprocessorOptions: {
    scss: {
      additionalData: `
        @use "@/styles/variables" as *;
        @use "@/styles/mixins" as *;
      `
    }
  }
}

真相大白！ Vite 内置的 additionalData 功能，已经完美地实现了全局样式注入。这意味着 style-resources-loader 在我的项目中，是一个完全冗余、没有被使用、但又带来了“历史包袱”的依赖。

✨ 第四站：执行“清除计划”

既然找到了问题的根源，并且确定了解决方案，那就开始动手吧！

1. 卸载冗余包

npm uninstall style-resources-loader --save-dev

终端显示 removed 24 packages，这感觉太棒了，一次性清理了24个不必要的依赖！

2. 彻底清理环境
为了确保没有任何残留，我执行了最彻底的“三板斧”：

# 删除所有已安装的包
rm -rf node_modules

# 删除依赖锁定文件，让 npm 重新计算依赖树
rm package-lock.json

3. 重新安装

npm install

这次，我紧盯着终端输出…

added 136 packages, and audited 137 packages in 28s

31 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

看！那两行烦人的 deprecated 警告彻底消失了！ 🎉 整个安装过程干净利落。

最后，我运行 npm run dev，项目成功启动，一切正常。

🏁 最终复盘

这次成功的“大扫除”行动，让我收获了几个宝贵的经验：

直面警告：不要忽视 deprecated 警告，它往往是项目依赖健康状况的“晴雨表”。
善用 npm ls：这个命令是排查间接依赖问题的“神器”，能帮你快速定位问题源头。
审视依赖：定期审视你的 package.json，特别是对于从旧项目迁移过来的配置，要思考一下：“在新的技术栈下，我真的还需要这个包吗？”
拥抱现代化：Vite 等现代构建工具已经内置了很多强大的功能。了解并使用它们，可以帮助我们移除很多旧的、非必需的依赖，让项目更轻量、更健康。

希望这次的排查经历能对同样被 deprecated 警告困扰的你有所帮助。给你的项目也来一次“大扫除”吧！Happy Coding! 💻✨

📊 总结与图表分析

📝 表格总结：问题与解决方案

阶段	遇到的问题	分析与原因	解决方案
1. 发现问题	`npm install` 出现 `deprecated` 警告	间接依赖 `inflight` 和 `glob` 版本过旧	警告虽无害，但影响开发体验和存在潜在风险
2. 定位源头	如何找到哪个包依赖了 `glob`	`package.json` 中无直接依赖	使用 `npm ls glob` 命令进行依赖树追溯
3. 分析“元凶”	`style-resources-loader` 是源头	该包已停止维护，且其功能在Vite中已冗余	Vite的 `additionalData` 选项是更好的替代方案
4. 实施修复	如何彻底移除旧依赖及其警告	仅升级无法解决，因为包已不维护	卸载 `style-resources-loader`，并清理重装依赖

🎨 流程图：依赖清理路径

🔄 时序图：开发者与NPM的交互

🏛️ 状态图：项目依赖的健康状态

🧩 类图：依赖关系简化模型

🗃️ 实体关系图：NPM包的依赖链

🧠 思维导图：依赖警告清理全景

🧹 npm install 警告清理行动
- 第一阶段：🚨 发现与识别
  - 现象：npm install 后出现 deprecated inflight 和 glob 警告。
  - 初步分析：
    - package.json 中无直接依赖。
    - 结论：问题源于间接依赖。
- 第二阶段：🔍 追踪与定位
  - 使用工具：npm ls glob 命令。
  - 锁定目标：发现警告由 style-resources-loader@1.5.0 引入。
- 第三阶段：🤔 分析与决策
  - 方案1: 升级
    - 检查新版本，发现已停止维护，方案不可行。
  - 方案2: 替代/移除
    - 审视其功能：Webpack时代的全局样式注入。
    - 对比当前技术栈：Vite 已通过 additionalData 内置此功能。
    - 最终决策：style-resources-loader 在项目中完全冗余，应予移除。
- 第四阶段：✨ 执行与验证
  - 操作步骤：
    1. npm uninstall style-resources-loader
    2. 删除 node_modules 和 package-lock.json
    3. 重新 npm install
  - 结果验证：
    - deprecated 警告完全消失。
    - 项目 npm run dev 正常启动。
    - 任务完成！ ✅