JavaScript npm包应该缩小吗?

Zan*_*der 10 javascript node.js npm

我创建了很多npm包,但我仍然不知道这个问题的正确答案:"JavaScript npm包应该缩小吗?"

我一直都明白,缩小缩小代码是一个坏主意,所以在我的npm包中没有这样做.但是,我看到一些npm包axios,样式组件提供了他们的"dist"文件的缩小版本以及未明确的版本,而Lodash没有.

哪个是对的?谁会消费缩小版?

Jef*_*amp 16

这一切都取决于您的包消费者的环境


的NodeJS

对于NodeJS受众,您的包不必缩小,因为节点运行时通常具有对文件夹的直接文件访问权限node_modules.不需要网络传输,并且在运行代码之前不会执行其他代码转换.


捆绑器/构建管道

对于通过在其构建管道中使用捆绑器的开发环境进行消费,最好不要缩小包.在大多数情况下,包装消费者确实将其自己的缩小过程作为其构建的一部分.此外,以模块格式提供包时,例如:

  • 可以更准确地分析实现代码库的依赖树,这可能导致更好的树摇动性能.
  • 跨包的公共依赖实际上所有这些包的相同符号(模块是'单例').这有助于代码拆分以及保持捆绑小.

上述声明依赖于这样的假设:如果包含多个源文件,则缩小之前是捆绑过程.缩小单独的模块是不常见的.如果确实提供了单独的模块,例如浏览器中的RequireJS运行时,则缩小仍然相关,因为这些文件主要通过网络获取.


如果您决定不提供缩小的代码,那么仍然建议您运行自己的测试,看看标准的缩小过程 - 例如使用UglifyJS - 是否会破坏软件.

尽管许多消费者无需缩小您的代码,但除了您的常规发行之外,仍然建议提供缩小的捆绑包,以防万一有人可以从中受益.

对于像Angular,Vue,Ember等框架的插件/扩展,通常不需要缩小代码,因为它们都经常通过cli实现自己的构建管道.


脚本标签/ CDN

这些是缩小主要针对的案例.如果您在CDN上托管文件,或者通过网络提供文件以便直接<script>使用标签,那么您所看到的就是您所获得的.在这两种情况下,文件都必须通过网络.缩小可节省字节数.


缩小与翻译

这两者之间有一个非常重要的区别.虽然微小并不总是必要的,这通常是你的责任transpile那是不太可能与你的包观众的目标环境100%兼容的任何代码.这包括:

  • 将新ES20XX语法映射到 - 可能 - ES5
  • 填充任何ES20XXAPI实现

缩小和捆绑

如果你的包装包含一个而不是一堆单独的模块,那么缩小是一个安全的选择.由于捆绑器永远不会尝试任何有趣的单个模块/实体(如树摇动),因此很可能您的代码在技术上根本不会因任何构建过程而发生变化.


调试

如果您要分发软件的缩小版本,那么出于调试目的而发送非缩小版本也会很不错.