过度使用导入很容易导致 JavaScript 文件体积膨胀至数兆字节。这是一个问题，因为这种体积会给网站的每个访问者带来负担，很可能延迟或阻止他们完成在网站上想要完成的操作。这对他们来说是不好的，对你来说更糟糕。
有很多方法可以监控它。
你可以在 Bundlephobia 上查看
Bundlephobia 会显示包的总大小（压缩和未压缩）以及下载时间、所需的子依赖项数量，以及它是否可以进行 tree-shaking（tree-shook？tree-shaken？）。
说到“恐惧症”，还有 Package Phobia 可以显示单个包的发布和安装大小。
你可以在 VS Code 编辑器中查看
使用 Import Cost 扩展，你的 import 和 require 语句可以让你了解特定包含项的大小。
你可以查看数据可视化
Webpack Bundle Analyzer 可以做到这一点。
你可以通过文本输出查看大小
Cost of modules 是另一个分析器，但它似乎只查看 package.json 而不是最终的 bundle，然后将其输出为表格。
Webpack Bundle Size Analyzer 将向你展示一个嵌套的依赖项权重列表，包括 bundle 代码本身的大小，这很有趣。
package size 可以显示以逗号分隔的包列表的体积
package size 有一个简单的 CLI 语法来实现这一点。
你是否有其他喜欢的控制项目体积的方法？
我使用 https://github.com/siddharthkp/bundlesize 和持续集成，如果 bundle 太大，构建就会失败。
最好的方法是学习原生 API 并学习如何真正编程，而不是为应用程序中的每一件事都使用库。;)
我知道你那里带了个眨眼的表情，所以这可能有点开玩笑。我理解这种观点，即可能过度依赖 npm 安装来解决问题，而忽略了对用户的成本。
但是，我会谨慎对待“学习如何真正编程”的态度。它听起来有点自负，可能会以用户真正不需要的方式羞辱初学者。
另外 - 注意那个 SSL 证书。
奇怪的想法，我一直认为，如果已经存在一个自行车，你就永远不应该自己创造一个。
不要重新发明轮子，但要根据可用的距离和时间选择合适的出行方式：步行（原生代码）、骑自行车（小型依赖项）或其他更大的交通工具 - 汽车、火车、飞机（大型 bundle）。
谢谢，Chris。 bundle 大小和依赖项经常被忽视。感谢您的提醒。我之前使用过可视化 bundle 分析器，但不知道其他工具。感谢分享！
你也可以在 pre-commit hook 中自动化这个过程。
(
lint-staged用于过滤提交的文件)在
package.json中，你可以配置 pre-commit hook 来启动lint-staged。然后配置 lint-staged（我使用
.lintstagedrc文件）。最后，回到
package.json中，你可以配置 bundle 大小。此方法仅在提交
_dist文件夹时有效。但你应该能够轻松地进行调整。