减小发布到npm包的体积与避免重复依赖

xiaotianyi 发布于2019-08-23 13:04 / 4265人阅读

摘要：我们可以把未经过打包的源代码发布到，并把中的字段指向源代码，这样引入的就交由项目的构建工具来进行处理，因此理论上就可以避免重复依赖了。总结通过这两天的折腾，主要收获有点发布包的流程中的字段判断重复依赖的机制基于组件封装组件时如何避免重复依赖

这两天一直在忙于封装一个vue table组件并发布到npm，记录一下我是如何把npm包的大小从100多kb减小到不足1kb的过程。

背景

这个组件底层依赖于element-ui，使用了其table组件和pagination组件，最终的组件是一个完全通过配置来描述每一列的表格组件。最开始我发布的是打包之后的代码。如果使用的这个组件的项目中没有引入过element-ui组件，那么不会造成任何重复的依赖，直接引用打包后的版本。但是如果项目本身已经引入了完整的element-ui(我们公司使用这个组件的10余个系统均引入了完整的element-ui)，那么很明显会造成代码的重复，会使bundle增加90kb(未压缩时)。

我们需要发布经过打包之后的代码吗

如果发布的经过打包后的组件，是没办法避免重复依赖的。如果可以像把源代码直接copy到项目再import引入这样，就可以避免重复的依赖了。这个可以使用package.json中的module字段来完成。

当package.json中存在module字段时，会优先寻找module对应的文件，并使用ES模块规范处理。

我们可以把未经过打包的源代码发布到npm，并把package.json中的module字段指向源代码，这样引入的package就交由项目的构建工具（webpack, babel）来进行处理，因此理论上就可以避免重复依赖了。

使用module字段是否会有副作用

有可能，因为webpack插件可以配置exclude字段，如果项目的webpack配置exclude掉了node_modules，就会产生副作用。比如可能未经babel转码成es5代码（我发布的这个组件目前只会存在这样一种可能的副作用）。

如何解决副作用

babel转码后再发布

在readme中指出，让用户取消掉babel的exclude

判断重复依赖的机制

到目前为止，还并不能解决重复依赖的问题。。。这是因为重复依赖的判断机制.Node.js中相同模块是否会被加载多次？

nodeJs是根据模块的路径来判断是否为同一依赖的，而大家都知道node.js会从当前模块所在目录的node_module开始找起，如果没找到再会去找上级目录的node_modules，直到根目录为止。那么问题就来了。

我发布的包里面dependencies里包含element-ui，这没问题，我确实依赖了element-ui。那么install包时，会根据我写明的dependencies下载element-ui并放在包的node_modules里面。所以这个包引用的element-ui和项目本身引用的element-ui由于path不同被认为是不同的依赖，于是都被打包进了bundle里面造成了重复依赖。

如何解决

方法1，在项目的babel配置中添加按需引入element-ui的配置，但是这个方法需要修改项目的配置，比较繁琐，我维护的10来个系统需要一个一个去改，太麻烦了。。。。

方法2，很简单，把发布的包的package.json的dependencies的element-ui和Vue删掉，这样npm install的时候就不会下载element-ui到包的node_modules,就是往上级目录找，直到项目node_modules里面的element-ui，这样，包引用的element-ui和项目引用的element-ui就是同一个依赖，就不会重复打包这和vue-cli3打包的库不会包含Vue依赖是同一个原理。最终的结果就是最终生产环境打包后的chunk-vender.js仅仅增加了不到1kb。

不过这样也造成了一定的问题，那就是本身不使用element-ui的项目需要手动引入打包之后的发布的文件。不过不使用element-ui组件的项目使用这个表格组件的收益和概率都不高，如果真的要用的话，多带带再发布一个完全打包之后的包，也能快速解决问题。

总结

通过这两天的折腾，主要收获有4点
1、发布npm包的流程
2、package.json中的module字段
3、判断重复依赖的机制
4、基于ui组件封装组件时如何避免重复依赖

GPU云服务器云服务器发布web应用到云端本地发布到服务器 asp发布到iis 发布网站到服务器

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/99198.html

webpack打包分析与性能优化

摘要：打包分析与性能优化背景在去年年末参与的一个项目中，项目技术栈使用，生产环境全量构建将近三分钟，项目业务模块多达数百个，项目依赖数千个，并且该项目协同前后端开发人员较多，提高构建效率，成为了改善团队开发效率的关键之一。 webpack打包分析与性能优化背景在去年年末参与的一个项目中，项目技术栈使用react+es6+ant-design+webpack+babel，生产环境全量构建将...

joy968 2019-08-20 14:21 评论0 收藏0
前端性能优化与上线

摘要：看下状态可以看到我已经有一些镜像了我已经删除了拉镜像正常即可，中间那段是中国镜像源，我们成功下来了的镜像。攻破像我这样屌丝的服务器一般都买的，大的资源文件不住，一个动辄的文件这很蛋疼，不上很难受。 4000字长文，多图预警！！！流量慎入！！性能优化 - 屌丝前端性能优化、上线一条龙大家好我又来了，本章给大家带来的内容是：上线和上线后的性能优化项目地址实战预览地址实战项目地址...

wupengyu 2019-06-28 16:51 评论0 收藏0
使用 NodeJS 构建现代化的命令行工具

摘要：前言这是一篇关于如何使用构建高性能高可读性的现代化命令行工具的博客。对于命令行工具来说，运行时的权限是巨大的，但不要因此弄脏用户的系统。前言这是一篇关于如何使用 NodeJS 构建高性能、高可读性的现代化命令行工具的博客。每当我们想要创建一个基于 NodeJS 的命令行工具时，就会衍生出一堆问题需要解决，比如如何准备开发环境，如何打包转译代码，如何使代码在转译后保持可调用的状态同...

QLQ 2019-08-23 18:15 评论0 收藏0
nodejs包依赖管理

摘要：鲜花总需要绿叶衬托的，对比的包依赖管理，顿时觉得包依赖机制真是漂亮。此文不吐槽的包管理是如何难用和混乱，也不去抨击包管理的孱弱，仅仅讨论如何优雅地使用进行包依赖管理。鲜花总需要绿叶衬托的，对比php, java, python的包依赖管理，顿时觉得nodejs包依赖机制真是漂亮。此文不吐槽python的包管理是如何难用和混乱，也不去抨击php包管理的孱弱，仅仅讨论如何优雅地使用npm...

chenatu 2019-08-22 11:03 评论0 收藏0
webpack V3.X 入门指南(完)

摘要：通俗的说，预处理器用一种专门的编程语言，进行页面样式设计，然后再编译成正常的文件，以供项目使用。在开发过程中，使用扩展名为的文件来编写样式 webpack 前言这篇文章是我在学习过程中对自己的一个记录和总结，也希望可以帮助到和我当初同样对webpack有困惑的小伙伴我在自学webpack时也参考了很多大神的文章，参考的帖子太多就不一一谢过了，再次感谢各位大神的帮助文章中的每个例...

Object 2019-08-21 17:23 评论0 收藏0