整个项目打包后总体过大,排查发现是公共库体积体积过大的解决办法
`1.分包：主要三个目的1.保证第三方库的指纹稳定，因为第三方库没被修改，打包生成的指纹是不变的，可以很好的利用浏览器缓存2.减少重复代码 3.动态加载 import definesynccomponent
- 尽量使用具名导入，以便配合tree shaing
3.跨项目公共库 内网可以自建cdn,外网：自建或者使用著名的cdn库 `
webapck vite
1.某个包出现多个版本的情况？
a依赖 依赖loadsh3.1.0 b依赖开始不是，但是升级为3.2.0， 就会出现一个包出现多个版本的情况
由于安装时间不一样， npm，yarn 会出现 两个版本的问题，由于依赖版本lock锁死的导致的
npm dedup
npm upgrade 或者 去删除lock文件可以解决
npm upgrade 更新到当前能更新的最新版本
比如^3.1.0 更新范围为ver>3.1.0 4.0.0<ver
~3.1.0 更新范围为：3.2.0 > ver > 3.1.0
2.如何知道 package.json 里的依赖有哪些更新了大版本， 也就是break change。
主要是更新了大版本之后，如果不及时更新依赖的话，拖的太久的话，可能会出现旧的官方文档被新的替换，导致旧版文档无处查阅，导致旧的项目无法维护。
原生的命令没有，但是可以借助第三方的 npm-check-updates 来知道
3. 什么场景需要更新依赖的最新大版本
-
新特性
-
break change
-
降低风险 Audit =》 npm audit 检查包是否被注入风险代码
4.如何发包
5.npm 私有仓库
项目规范
-
代码
-
eslint
-
-
脚手架
- 项目结构统一
- 工具包统一
-
husky : 提供一套 拦截 git hook的 工具集 - git hooks : .git > .hooks 下有一套脚本 【但是可以配置 hooks 的默认路径】【修改.hook s的目录改为受git 控制的目录， 然后在该目录下编写pre-commit 脚本。就可以实现不使用husky，来实现拦截git【husky原理就是如此】】 - 自己在cli 窗口敲git 命令的时候，在进入到pre-commit脚本里写入相应的逻辑。
-
lint-stage ： 可以对 git add 之后的暂存区做一些命令操作！！！
- 不借助于 lint-stage ，如何对暂存区做执行一系列？ git diff --cached
-
xargs
-
glob
- 找到所有的.json : **/*.json
- 找到所有的[a-z].json : {a..z}.json
-
文档
-
npm lifecircle
-
git commit 项目规范
- commit-msg
-
'zx'
-
组件规范
- 层级 分层设计
-
npm 分包 发包
- webapck
- 入口文件字段： main/module 一般是commonjs，esm
- types
- webapck
-
commonjs Esm 区别
-
工具库
-
rollup webapck 做工具打包遇到的问题：
-
打包后的目标格式 ： umd[] cjs[] esm[output 选项里有个选项]
- 默认的格式： iife
-
-
webapck chunk 如何生成： import() | code spliting |
-
peerDependencies 字段（自动安装，项目中存在的话就不会自动安装） | peerDependenciesMeta 字段
-
pnpm ： 优势： 省空间【软连接】
【使用 pnpm （项目初衷 | pnpm中文文档 | pnpm中文网）时，依赖会被存储在内容可寻址的存储中，如果你用到了某依赖项的不同版本，只会将不同版本间有差异的文件添加到仓库。
所有文件都会存储在硬盘上的某一位置。 当软件包被被安装时，包里的文件会硬链接到这一位置，而不会占用额外的磁盘空间。 这允许你跨项目地共享同一版本的依赖。
在项目安装依赖时，会进行依赖解析，对已经安装的全局包直接软链接到项目中。 】
-
幽灵依赖 【就是package.json 中dependency不存在这个包，但是项目中又存在间接依赖，但是又恰好引用了这个包】【.pnpm下才是真正的依赖】【找其他的包的时候，node_modules下对应不存在，就会软连接连接到.pnpm 里了，命名：自己的包名+peerDependencies才是.pnpm 里的包的全名】
-
如何确定包管理工具
- lock文件
- engines
- packageManager 字段确定版本号
-
corepack
-
docker ci cd
