如果您是一家高档米其林星级餐厅的厨师，您会从未经验证的随机来源购买蔬菜和肉类吗？几乎任何一个普通项目的成本都以数十万甚至数百万美元衡量。我相信我们的行业应该采用与餐馆相同的方法。 例如，无需安装额外的库来生成 UUID。 Node.js 和浏览器开箱即用地 它：  立即问自己的第一个问题：你真的需要一个新的依赖项吗？是否可以使用当前环境（例如语言或已安装的库）解决问题？ 支持 crypto.randomUUID() 例如，如果你只需要一个下拉菜单，是否值得安装像 Bootstrap 这样的东西？也许最好将自己限制在一个单一的、集中的库中，并使用 ？ 第二个问题：需要整个图书馆吗？ 来自 Radix UI 的无样式下拉组件 好的。我们心中有几个候选人。那么，我们如何选择合适的呢？ 格式精美的自述文件？一个家喻户晓的名字？比其他人更多的叉子、星星和下载？不幸的是，仅仅这些因素是不够的。在这里，我们正在选择一个服务提供商。我们希望出现的任何问题都能得到快速解决，功能保持最新，最重要的是，服务安全可靠。简单的外部指标并不总是表明质量或长期适用性。 在安装我们在存储库目录中找到的内容之前，最好访问 GitHub 存储库并分析其内容。 我准备了一份过去几年我一直在使用的标准清单。我希望他们能帮助你选择最合适的图书馆。必须全面考虑它们，并且在某些情况下，在它们之间进行选择时做出妥协。 我不是在批评下面提到的库或试图阻止它们的使用。在某些情况下，我故意省略了名称以专注于标准示例，同时保持事实的准确性。 免责声明：  1. 安全 使用起来有多安全？这听起来像是虚构的，但是是的，依赖性可能是危险的。例如，一个有趣的功能 到一个有 50 万次下载的库中：如果您的 IP 地址在特定范围内，它会尝试用 ❤️ 替换计算机上的所有文件。 被添加 一个有趣的事实是，这个依赖被用在了 中。我们怎样才能发现这样的问题呢？检查问题页面，或尝试通过图书馆的名称进行谷歌搜索。通常，此类信息很快就会浮出水面。  vue-cli  2.保养 最后一次发布是什么时候？发布的频率如何？定期发布确保问题得到解决，更新支持不断变化的技术。在移动开发的背景下，定期发布也能确保项目编译成功。 这里有一个来自围棋世界的例子：一个拥有 18.2K 星的库的作者决定停止维护他们的依赖并将其归档。这意味着，几年后，缺乏支持和更新将成为一个问题。现在想象一下在不首先检查 GitHub 的情况下安装类似的依赖项。这是一种检查产品的到期日期。  以下是频繁发布的良好示例：  3. 打开/关闭的问题 未解决问题与已解决问题的比率是多少？作者接受更改的意愿如何？有可能有一天您可能需要贡献一些东西。例如，这个库非常受欢迎，并且有 98% 的已关闭问题。只有 18 个开放。 解决关键问题的速度有多快？有一次，我选择了一个 31k star 的 ORM，但是在某个时候，我们遇到了一个问题，把我们挡住了。我们不得不寻找解决方法并最终切换到另一个解决方案。不幸的是，快四年过去了，问题仍然没有得到解决。 可以通过按评论最多的问题排序来识别此类问题。 贡献过程是否由创作者组织？是否有清晰明确的工作流程？例如，Next.js 的创建者甚至录制了一段 40 分钟的视频来介绍他们的贡献过程。  4.代码质量 是的，可能有很多代码，但总是可以检查它的不同部分。该项目是如何组织的？它是否易于理解，结构合理，良好做法是否适用？代码写得越差，未来项目消亡的可能性就越大。对于我来说，这个阶段淘汰了很多小候选人。  5. 测试覆盖率 图书馆有考试吗？什么是测试覆盖率？测试是如何编写的？即使维护人员审查合并请求，也有可能会忽略某些事情。有很多不同的人为图书馆做出贡献。通常，测试覆盖率信息显示在存储库顶部的徽章上。但是，如果不是，我们可以随时在项目中搜索测试。例如，  库系列具有出色的测试覆盖率并包含各种类型的测试。 formatjs  6. 文库大小 移动应用程序通常具有较大的依赖大小，整个应用程序甚至可能超过 200MB，这可能会导致蜂窝网络下载过程中出现问题并占用大量存储空间。这对于前端 CSR 应用来说尤其成问题，因为网速慢会显着增加加载时间。 对于 Web 项目，有一个很棒的工具可以确定包的大小：   。当然，服务器端渲染和 tree shaking 可能会减小尺寸，但这需要始终验证。 https://bundlephobia.com 一个流行的例子是日期操作库。   (2.9KB) 提供的功能可能就足够了，无需安装  (72.1KB) 或  (26.8KB)。 dayjs moment.js date-fns  7. 依赖数量 上面列出的所有点在某种程度上都乘以项目整个依赖树中的依赖项数量。检查完整依赖树的好工具：https:  //npm.anvaka.com  8. 执照 你有没有想过这个？我也没有。例如，MIT 和 Apache 2.0 许可证允许在商业项目中免费使用库，而一些 GPL v2 许可证有特定的要求和限制。在我们的一个项目中，我们有一张由律师准备的表格来检查我们所有的依赖树的许可证。因此，如果您在许可证中看到异常情况，最好咨询律师，以免在审核过程中出现问题。我们可以使用 实用程序从现有的 npm 依赖项中提取所有许可证。 PS 我不是律师，这不是法律建议。由于许可证的原因，某些东西可能不适合，这是一种罕见且特殊的情况，但它仍然是可能的。 legally 结束！ 感谢您阅读我的文章！它的关键点是展示真实世界的例子，即浅薄和快速的决策有时会导致不是最好的选择。通过考虑这些标准，您将能够做出更明智的决定。 请随时留下您可能有的任何意见或建议。也不要犹豫，在评论中分享您的经验。你的喜欢和评论激励我写新文章。快乐烹饪:)

Read My Stories

該音頻是用故事的原始語言製作的！

选择正确的依赖项：综合实用指南

About Author

註釋

標籤

这篇文章刊登在

Related Stories

扬帆起航：利用数据湖开发生产级 RAG 应用程序

看不见的层面：为什么用户访谈是不可替代的资产

点击赚钱：Telegram 可能会在 Solana 之前吸引下一个 100 亿加密用户

使用这 18 种开发工具来提高你的工作效率 🚀🔥

扬帆起航：利用数据湖开发生产级 RAG 应用程序

看不见的层面：为什么用户访谈是不可替代的资产

点击赚钱：Telegram 可能会在 Solana 之前吸引下一个 100 亿加密用户

使用这 18 种开发工具来提高你的工作效率 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps