前端依赖去重实战指南用 Front-End-Checklist 的 duplicate-js 规则消除重复 JavaScript 库【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文基于 Front-End-Checklist 仓库中skills/duplicate-js/SKILL.md及其详细参考文档skills/duplicate-js/references/rule.md展开讲解如何检测并合并项目中的重复 JavaScript 库如同时存在多个 jQuery 或 Lodash 版本从包管理器、浏览器控制台、第三方标签三条路径定位问题并给出包覆盖overrides、依赖去重、peerDependencies 等修复方案。读完本文你将掌握一套可复用的「检测 → 合并 → 验证」工作流用于缩小打包体积、降低内存开销并消除版本冲突导致的运行时 Bug。规则定位performance 分类下的中优先级清单项duplicate-js是 Front-End-Checklist 仓库中skills/目录下的一个结构化技能skill其元信息skills/duplicate-js/SKILL.md给出了该规则在清单体系中的定位字段值含义categoryperformance属于性能检查大类prioritymedium中优先级difficultyintermediate适合有依赖管理经验的开发者estimatedTime15预计耗时 15 分钟sourcefrontendchecklist.io规则来源为 Front-End Checklist 网站该技能在前端清单中也有对应条目README.md将 Remove duplicate JavaScript libraries 列为中优先级的待办检查项说明其核心目标是detect and consolidate duplicate JavaScript libraries to reduce bundle size and prevent version conflicts检测并合并重复的 JavaScript 库以减小打包体积并防止版本冲突。在仓库的内容体系中duplicate-js与js-libraries、legacy-js、javascript-minification、browser-caching同属性能/metrics 检查区并互为关联规则见packages/content/rules/en/performance/js-libraries.mdx的relatedRules声明其中明确给出duplicate-js的关联原因 Both rules sit in theperformance/metricsarea and are commonly reviewed together。这说明去重工作通常与「库安全与更新」「移除旧版 JS」「压缩体积」等检查搭配进行构成一次完整的 JS 依赖健康审计。为什么重复库是性能与稳定性的双重隐患skills/duplicate-js/references/rule.md指出加载同一库的多个版本例如两个版本的 jQuery 或 Lodash是页面超重和潜在运行时错误的常见原因。其负面影响可以拆解为四个维度打包膨胀Bundle Bloat每一个重复库都会增加浏览器需要下载、解析和执行的 JavaScript 总量。在packages/content/rules/en/performance/js-libraries.mdx中也有类似判断——库通常占据 Web 应用 JavaScript 的主体优化它们收益最高。内存开销Memory Overhead同一库的多个实例会占用更多内存在低端设备上表现尤为明显。版本冲突Version Conflicts不同版本可能有不兼容的 API 或共享全局状态导致难以排查的 Bug。执行时间Execution Time浏览器在渲染流程的 Compile Script 和 Evaluate Script 阶段花费更多时间。第一步Check —— 如何检测重复库技能文件skills/duplicate-js/SKILL.md给出的检查动作是使用 Lighthouse 或打包分析工具识别重复的 JavaScript 库或同一库的多个版本。具体有三条实操路径。1. 用包管理器查询依赖树references/rule.md推荐使用包管理器直接查询某个依赖在依赖树中出现的版本数量# npm 项目列出 lodash 的所有被安装版本 npm ls lodash # pnpm 项目解释为什么 lodash 会出现在依赖树中 pnpm why lodash对于本仓库这种使用 pnpm workspace 的 monorepo根目录存在pnpm-workspace.yaml与pnpm-lock.yamlpnpm why package尤其有用它能追查出是哪个中间依赖把旧版本带进了依赖树。2. 在浏览器控制台检查全局变量当重复库以多个全局变量形式存在时例如 CDN 脚本和应用打包产物各加载一份可以在控制台直接探测// 检查是否存在多个 jQuery 版本 console.log(jQuery version 1:, window.jQuery?.fn?.jquery); // 某些脚本可能把 jQuery 起个别名例如 window.$ 或 window.jQuery3. 用打包分析工具可视化确认references/rule.md的 Best Practices 强调在去重之前先用 Bundlephobia 或本地打包分析器确认问题因为真正的问题通常是树中某个重量级依赖被重复了而不是所有共享工具库。常用工具包括webpack-bundle-analyzer以可交互缩放的矩形树图treemap可视化 webpack 输出文件的大小rollup-plugin-visualizerRollup 生态的等价物Lighthouse其审计项会直接标记 duplicate modules in JavaScript bundlesJSHint可辅助识别全局变量冲突。第二步Fix —— 合并依赖到单一版本检测到重复后skills/duplicate-js/SKILL.md给出的修复动作是合并依赖到单一版本并确保第三方脚本不会带入冗余库。references/rule.md提供了三种具体手段。1. 使用 package.json 的 overrides 强制单一版本当不同的子依赖各自要求不同版本时可以通过overridesnpm 与 pnpm 均支持强制统一// package.json { overrides: { lodash: ^4.17.21 } }注意overrides是「有时候」可行you can sometimes force a single version——它适用于各依赖对新版本兼容的场景如果某个子依赖强依赖旧版 API则需要先升级该子依赖本身而不是盲目覆盖。2. 定期执行依赖去重命令# npm 项目 npm dedupe # pnpm 项目 pnpm dedupereferences/rule.md将其列为最佳实践作用是清理 lockfile 中重复的间接依赖。3. 作为库作者使用 peerDependencies如果你是库的维护者应使用peerDependencies声明宿主环境需要提供的依赖而不是把常用库如 React、Lodash直接打进自己的依赖树从而避免强制用户安装重复版本。本仓库的 monorepo 结构pnpm-workspace.yaml管理的多个packages/*子包正是这种依赖隔离与共享并存的典型场景。4. 审计第三方标签references/rule.md建议使用 Google Tag Manager 或类似工具审计第三方脚本——很多第三方脚本会自带它们的依赖副本例如自己打包一份 jQuery。这正是 SKILL.md 中 Audit third-party scripts for bundled dependencies 的落地场景。修复时还需避免「CDN 加载一份 主应用打包一份」的双重加载模式对应最佳实践中的 ❌ Avoid Multiple Global Libraries。第三步Explain 与 Code Review —— 面向人和 Agent 的规则使用该技能的设计对 Agent 友好SKILL.md 的description元信息明确写道 Use when auditing slow page loads, heavy assets, or rendering delays related to Remove duplicate JavaScript libraries并要求在推荐修改前先通过 DevTools、Lighthouse 或现场数据field data验证真正的瓶颈。Explain向团队解释加载重复库的风险及其对性能与稳定性的影响即上文的四大隐患。Code Reviewskills/duplicate-js/SKILL.md要求审查与去重相关的路由、资源和加载行为标记出确切增加网络、CPU 或布局开销的文件、请求或渲染步骤并说明用于确认问题的测量方法——强调精确到文件与请求级别的可信度而不是笼统地说有重复。第四步Verification —— 验证去重是否真正生效references/rule.md的 Verification 章节给出了两类验证手段保证改动是可测量的自动化检查在 Lighthouse、PageSpeed Insights 或 DevTools 中测量受影响的页面或流程确认目标指标如 JS 字节数、脚本执行时间确有改善检查网络瀑布流network waterfall或性能时间线确认预期的资源或执行变化真正生效。手动检查在限速的移动端 profilethrottled mobile下验证改动而不是只在本地桌面环境验证如果该规则对应某个预算budget或 Web Vital确认页面现在保持在阈值之内。这一「先测量、再修改、再复测」的闭环与仓库中其他性能类规则如legacy-js、preconnect、dom-size保持一致它们都在relatedRules中与duplicate-js互相关联。一条完整的工作流建议综合 SKILL.md 的 Quick Reference检测并移除同一库的多个版本 → 全应用使用单一版本 → 审计第三方脚本的内置依赖与 references/rule.md落地一条可执行的工作流测量在 DevTools / Lighthouse / PageSpeed Insights 中记录当前 JS 体积与脚本执行耗时作为基线检测npm ls pkg/pnpm why pkg定位重复版本配合webpack-bundle-analyzer可视化确认哪些依赖占了体积修复能统一版本就用overrides能清 lockfile 就npm dedupe/pnpm dedupe库作者改用peerDependencies同时审计 GTM 等第三方标签是否自带依赖复测在限速移动端 profile 下重跑 Lighthouse确认目标指标改善、网络瀑布流中多余脚本消失。参考与延伸阅读技能文件skills/duplicate-js/SKILL.md规则细节参考skills/duplicate-js/references/rule.md清单中的对应条目README.md关联规则库安全与更新见packages/content/rules/en/performance/js-libraries.mdx旧版 JS 见legacy-js.mdx完整规则目录docs/generated/rules-catalog.md度量标准以 web.dev 的 Learn Performance 与 Chrome Developers 的 Lighthouse 概览作为生产环境最终行为的度量标准而不是只看本地合成数据参见references/rule.md的 Standards 章节【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考