在最近的一次开发中，我引入了dayjs这个用于处理时间格式和设置时间的功能包。然而，在部署到服务器时遇到了一系列问题。
一、问题排查与解决
1.缺少依赖包报错
在完成功能开发后，进行服务器部署时，通过查看日志发现报错信息显示缺少刚引入的dayjs依赖包。日志如下:
令人意外，查看构建脚本后，发现构建命令为yarn run build，而其中竟然没有执行install操作，这就导致了新引入的依赖未被安装到服务器环境中。
由于项目同时存在package-lock.json和yarn.lock文件，且package-lock.json较新，我决定使用npm install来安装缺失的依赖。
2.权限问题
手动执行了npm install之后重新构建，结果提示没权限。
这是因为在之前的操作中使用了root用户，这改变了node_modules目录的所有权。为了解决权限问题，将node_modules目录的所有权重新分配给jenkins用户：chown -R jenkins:jenkins /xx/xx/node_modules*。
3.类型检查错误
执行完上面的操作解决了依赖安装和权限问题后，构建过程中又遇到了类型检查错误。
这是因为install过程可能无意间升级了一些依赖包，导致不兼容。为了快速解决问题，暂时关闭TypeScript的类型检查（移除了tsconfig.json中的include字段），从而使得构建能够顺利完成。
二、优化依赖管理
经过对 package-lock.json 与 yarn.lock 内版本信息的仔细比对，我判断该项目首次上线时，采用的是 yarn 来管理依赖包与进行项目构建。后来，不知何人添加了 package-lock.json。
令人惊讶的是，在此后的两年时间里，竟无一人引入新的依赖。这就解释了为何之前在服务器上构建从未出过问题（毕竟没有新插件引入，node_modules 始终未更新，构建自然全部成功）。然而，我在服务器上手动执行安装操作时，服务器 node_modules 内的依赖依据 package-lock.json 中的版本进行了升级，最终引发了兼容性问题。
为了避免未来再遇到类似的依赖管理问题，采取了以下措施：
- 鉴于项目早期使用的是
yarn，jenkins上构建也是使用的yarn，决定统一采用yarn作为唯一的依赖管理工具，并移除package-lock.json。 - 为了防止意外升级依赖包，在
package.json中去掉了所有版本号前的^和~符号，这样可以确保每次安装时都使用确切的版本号。 - jenkins构建脚本设置为
yarn install和yarn build，确保每次构建都先执行依赖安装，防止缺少依赖。
最后再来对比下package.json中的依赖版本。
旧的
新的
服务器上构建。
