接手工程化

年底了，有必要好好总结实习以来所做的工作～刚入职时，mentor 大哥和我说，团队的工程化存很多的优化空间，希望我后续能先从这切入，没想到这一切入，就过去了一个学期🌝。

对于我这个工程化小白来说，内心是非常不自信的，但转头一想，这无疑是一个宝贵的锻炼机会，平时靠自己也很难接触到这一类的东西，因此也是狠狠给自己打了一波鸡血------ 啥也不会，那先开卷！

这篇文章主要是想分享一下我在工程化需求开发的过程，提供一些学习工程化的建议，并不涉及具体的技术细节，大佬们可以当个乐子放松放松。

做了些啥

一个学期下来，虽然做的事情不多，但在看到成果转化有收益时，会有很大的成就感。下面聊聊我具体做了什么东西。

支持路径别名 和 monorepo 源码引用 单独实现其实并不麻烦，但结合在一起实现却需要注意很多方面的问题。但是核心绕不开对编译器和构建工具的配置。

只需要在目标项目中配置 tsconfig.json 的 compilerOptions.path，同时在构建工具配置中设置相应的 alias 即可。

在目标项目中配置 compilerOptions.path，引用方设置相同的路径别名，通过 references 配置指定引用目标项目，一个简易的实现就完成了。

我们在基于 支持路径别名 之后，通过在引用方的构建工具中配置一个插件，读取目标项目的 alias 并设置，就可以简单实现编译器和构建工具对路径别名的源码引用和路径提示 。

最最最大头且头大的玩意，从最开始的估时一周到接近三个月的开测时间，被形形色色的 Error 折磨的五体投地。

本以为通过制定的升级包一键升级即可，但升级之后，各种配置策略的变化，项目本身的自定义需求，都产生了极大的问题。

然而在整个过程中，还是学到了很多东西，也是想着后续逐个写成文章分享出来,比如：手写插件实现外部 CDN 插入 html 模版，研究 babel-runtime 对包体积的优化，针对生产、开发环境做不同打包策略，如何有效拆包......

这是最简单的需求了，通过司内包升级了老旧的 lint 工具，同时依据之前的代码规则，对新的规则集做了个性化配置，后续要逐步把一些暂时 off 掉但有用的规则重新启动，维护项目的代码质量。

为了提高代码的安全性，需要在 CI 上设置 lint 检查和 ts 类型检查的卡点，为此我申请独立开了一个存放脚本的仓库，对一些基本操作（通用执行原子任务、记录原子任务执行时间等）做了封装，以便后续新增更多的卡点需求。

关于代码实现，我在代码管理平台上设置了触发流水线，通过指定的 shell 脚本执行对应的 ts 文件，实现的操作有：安装 nvm，选择合适的 node 环境 -> 拉取指定代码，安装依赖 -> Lint 检查 -> ts 检查 -> 输出日志。

于此同时，在项目本地也相应地添加了相关的检查点。

截止年前基本就完成了这几件事，年后还有一堆安排在等待中，真是痛并快乐着啊😭😊。

对于收获，我在工程化的很多方面都得到了质的飞跃，已经彻底摆脱了唯唯诺诺的自己。

在真正打开工程化的大门之后，我也逐渐找到了节奏，希望在接下来能越走越深，早日做到 owner 团队的工程化，但也要争取做一些业务。对于工程化，建议没接触过的同学一定要结合实际的需求去做做，虽然机会比较少，但一定要争取争取。

在平时 coding 中，可以主动地探索项目工程化的优化方向，结合社区建议实现相关的方案，多搓 demo 练练手，能力会在不经意间沉淀出来～（可以多和技术友交流方案，也可以来狠狠拷打我🌞）

举个例子，在一个项目开发过程中，把遇到的所有不爽的点整理一下，思考能否用工程化的思路解决，比如：

与此同时，要虚心向 mentor、师兄师姐多多学习，多多观察工作习惯，主动咨询各种开发经验 ，谦虚且厚脸皮肯定混的不差👍！

简简单单：转正！能不能给我拿个 ssssssssp ！（一本正经

最后，新的一年，希望能静下心来，读一些好书，在工作之余将学到的东西整理成文章分享出来。忙碌之余，也要认真看看世界，享受一下生活，加油！