工作日志 2023/3/30

今天依然处理了一整天的vitepress项目构建问题。

从昨天负责编写公共库的同事反馈文档项目无法构建起，我已经排查并解决了一系列的问题，其中主要是：

（1）构建所依赖的外部包版本问题；

（2）vitepress 服务端渲染（SSR）兼容问题

（3）多工作区项目之间的引用问题

对于问题（1）构建所依赖的外部包版本问题

最终的解决方案是比对了ElementPlus文档项目（我们的文档项目，是基于elementPlus文档项目的实现）中使用的包版本，跟其保持一致。问题出在我们的文档项目所使用的vite依赖包高于elementPlus

对于问题（2）

原因是文档项目所引入的内部人员开发的公共依赖库存在对SSR不友好操作，比如在文档导入时即操作了dom，在不好修改所依赖的对SSR不友好三方库的情况下，vitepress官方提供了一些ssr兼容方案，其中一些方案需要升级vitepress版本，由于改动较大，临时使用动态导入三依赖包的方案。

对于问题（3）

虽然目前我们的文档项目和另外的几个公共库项目放在同一级目录下，但并未采用多工作区的源码管理策略(吐槽：模块引用混乱，构建繁琐，建议架构人员学习下element的源码管理，好好设计下源码结构)；

文档项目所参与的文档及Demo编写人员起初是通过设置相对路径别名引用了公共组件库源文件，这种引用方案导致构建文档时会连带组件库源文件的构建，难以实现自动化部署，所以需要全部替换为引入外部依赖包的方式；

（3.1）由于vitepress在构建期间使用vue的服务端渲染功能在node.js中预渲染应用程序，我们的web公共组件库至少需要构建为es、cjs两种格式的包文件，此处又了解了组件库构建配置、包文件路径映射等内容

到此，三个问题解决完毕后，我的文档项目已成功构建并配合运维人员实现了自动化部署工作。

后续问题

在顺手配置了公共组件库以构建出SSR兼容的包文件后，出现了两个问题：

（1）负责编写公共组件库的同事反馈在文档启动开发服务运行项目后，动态导入的内容为undefined，

（2）在业务项目中使用公共组件库的同事反馈构建的包抛出很多错误

对于问题（1）

我启动文档本地服务后，确实发现了此问题，我联想到是包文件映射的问题，因为动态导入时es语法，只有基于es语法的包文件才能正确导入，若导入的是其他包文件，大概率会产生这个错误，检查公共组件库的package.json文件后，exports.import映射的路径非es module包文件，修正后，打包，手动copy到docs项目中的node_modules目录下后，重新运行项目，发现错误仍然存在，在又尝试了一次后我陷入了迷惑；后来我再构建好的文件中埋点，运行测试发现并未执行我的新增代码，我终于了解到是包缓存问题，我又了解到了vite的依赖预构建机制，在手动删除vite缓存后，再次执行，结果是成功导入了正确的es包文件，问题解决了。

对于问题（2）

我运行了业务项目，看到了抛出的问题，经过分析很快就发现是依赖包版本不一致导致的问题。原因如下：

我们的公共组件库引用的three包的版本是0.125.1，而业务项目中也引入了three包，版本是0.150，当业务项目中用yarn去安装依赖的时候，由于依赖包版本不一致，公共组件库和业务项目在各自目录下装了不同版本的three依赖包，引发了兼容问题，导致了一些ts类型报错。

目前的解决方案是：在公共组件库中的package.json文件中删除three依赖项，这样在业务项目中引入公共组件库时只会安装一份three，就暂时不会产生兼容问题。

我终于明白为什么我运行公共组件库时项目明明引入了three，package.json中却没有相关依赖项。我对此种方案无法接受（但是由于我不是主要负责人，而且很晚了，暂时没有过多去查找其他解决方案），因为我想到在其他情况下会产生的问题，比如：

1.如果我们有了新的业务项目，当前业务项目无需引入three包，但需要引入当前的公共组件库，由于没有在package.json中生命依赖包，到导致三方公共库报错。

2.如果我们的新业务项目中引用了three包，但是比公共组件库高或低很多个版本，那势必会与组件库中的three依赖产生兼容性问题。

今天的问题虽然处理完了，但是也留下了一些疑问，此时夜已经很深了，就留给明天去探索吧！