组件分层设计思路
基础 UI 层：无业务 业务层组件：由基础 UI 组件组成，跟业务挂钩，例如一个查询组件封装了查询条件，表格和导入导出，同时跟后台接口约定一些固定传参字段，封装在里面。
npm 发包
Verdaccio 私包
package.json 入口模块字段
main: 默认主入口，当库被其他项目通过require引用时，默认读取该字段指定的文件，否则用根目录下的index.js。module:esm入口，用于import或export语句中。直接利用 ES 模块的静态结构，以实现 tree-shaking 等优化。browser：指定了一个专为浏览器环境设计的模块入口，提供了浏览器的兼容版本。例如 node 用http，而浏览器中用xhr。types:TS类型文件exports: 允许库定义多种导出方式和路径，以便根据用户的环境（Node.js 或浏览器）或CommonJS/ESM来提供相应的版本。peerDependencies: 使用外部项目的依赖。看有没有所需的依赖包，没有的话会自动安装，有的话就不安装，版本不匹配只发出警告。peerDependenciesMeta: 提供关于peerDependencies的额外信息。例如optional: true指示某些peerDependencies是可选的。engines: 指定项目所需的 Node. Js 或 npm 版本，不符合将会有警告或报错。packageManager：主要服务与 node 的corepack enable。确定项目中配置packageManager的包管理器及版本，并自动下载使用。bin：指定可执行文件的路径，主要用于编写一些命令行工具，使目录下的命令行工具可以直接被调用。
如何确定项目中包管理工具
- 看
.lock文件。 - 如何确定项目中包管理工具的版本号？
enginespackageManager：node 的corepack enable: 自动确定项目中配置packageManager的包管理器及版本，并下载使用
commonjs / esm 区别
都是模块系统规范
静态分析
esm：支持静态分析，编译时可以取得模块依赖，进行 treeShaking。 commonjs: 由于模块的导入是动态的，这使得静态分析和优化（如树摇）变得困难。
兼容性
esm：现代浏览器和最新版本的 Node.js 支持。未来的基调。 commonjs：广泛应用于 Node.js 环境。
同步/异步
esm： import()支持异步加载。 commonjs：require() 模块是同步加载的，主要用于服务器环境（如Node.js）
pnpm
痛点 - npm / yarn 体积占用过大问题
方案：
- 使用软链接/硬链接
- 解决了 npm/yarn 平铺
node_modules带来的依赖项重复的问题。
硬链接：与源文件指向同个地址，属于同个文件，有相同 inode。项目中 node_modules/.pnpm 跟全局共享。
软链接：指向源文件的指针，属于单独一个文件，体积几字节，有不同 inode。node_modules 的依赖包的依赖指向 node_modules/.pnpm。同时因为用了软链接，可以在文件名上带版本号。
依赖项重复：4 个包引用同个依赖，但版本不同，两个 3 版本，两个 4 版本，抽出来一个，剩下两个得放在各自的 node_modules 中，重复了。
依赖项重复时，3 版本 4 版本为什么不能都抽出来？ 抽出来文件名重了，只能通过修改文件名例如带版本不重，而 node
require通过文件名去找，不能通过文件名，否则找不到。解决方案就是软链接。
痛点 - 幽灵依赖
幽灵依赖：项目里用了不在 package.json 声明的依赖。
npm/yarn： 依赖的依赖平铺在 node_modules 中，才有机会产生幽灵依赖。
pnpm ：只有 package.json 声明的包依赖才会在 node_modules 中，依赖的依赖没有平铺 node_modules，而是通过软链接指向 node_modules/.pnpm。
引用不在 package.json 声明的依赖时，因为 node_modules 中找不到就直接报错提醒了。
rollup ??？
webpack
- 目标格式
output.library.type可以配置，默认var导出全局变量。生成一个全局变量的声明和iife。umd/cjs/esm/iife??
chunk如何生成import() API=>async chunkcode spliting=>chunk根据opxxxxx规则根据大小引用次数进行分包 ??