背景说明
在使用Rollup构建企业代码库的时候，对于其使用方式，尤其是依赖管理存在一些疑虑，加以分析说明。
Tree-Shaking
与传统的 CommonJS 和 AMD 这一类非标准化的解决方案不同，Rollup 使用的是 ES6 版本 Javascript 中的模块标准
目前比较明显的一个问题是，我们所依赖的第三方包，或者现有构建的umd包一般会遇到冗余打包的问题。
tree-shaking就是一种将未实际用到的代码剔除的机制
如果你的 package.json 文件具有 module 属性，像 Rollup 和 webpack 2+ 这类 ES 模块识别工具可以直接导入模块的 ES module 版本。
通常，库会附带一个package.json文件（例如，如果您在 npm 上发布，这是强制性的）。该文件通常会指定一个pkg.main属性 - 如下所示：
这会指示 Browserify 或 Webpack 或 [在此处插入模块捆绑器]在您调用应用程序或库dist/my-package.js时在您的捆绑包中包含内容（以及它所具有的任何依赖项）。require(‘my-package’)
但是对于像 Rollup 这样的 ES2015 感知工具，使用 CommonJS（或通用模块定义）构建并不理想，因为我们无法利用 ES2015 模块特性。因此，假设您已将包编写为 ES2015 模块，您可以在 CommonJS/UMD 构建旁边生成一个 ES2015 模块构建：
依赖管理
针对 esm 与 cjs 类型，因为经过 rollup 编译后代码，还是会被组件库的使用者再次引用，并编译打包，所以我们没有必要把 babel 运行时的代码打包进入，因此这里将 @babel/runtime 的代码也排除了，但是 @babel/runtime 会作为组件库的 dependencies 存在，也就是说，组件库使用者，在使用时一定会下载 @babel/runtime ，从而保证组件库整体的正确
————————————————
版权声明：本文为CSDN博主「mjzhang1993」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mjzhang1993/article/details/112575745
意思是，假如我们的lib依赖qs，但我们并不希望将其打包，因为其他组件库也有极大概率使用（会重复打包吗？？），但是在工程中难道我们需要自己安装qs吗，不用，将qs作为dependence依赖但不打包。工程使用lib会安装这个依赖的依赖，且打包的活是工程在干。假如说这个不是qs而是react那么一定还要考虑整个生态的一致性，因此不仅仅是dependence还需要peerDependence
对等依赖的基本概念
Rollup依赖机制
按需引入组件实现
相关资料
https://classic.yarnpkg.com/en/docs/dependency-types/