Time Machine同步备份到新Mac
发表于
更新于
本文字数：
846
阅读时长 ≈
1 分钟
本文是作者对Time Machine同步备份到新Mac的介绍，包括Time Machine同步备份到新Mac的优势、实现细节、相关资料等，这些步骤可以帮助作者提高Time Machine同步备份到新Mac的效率。
聊聊HTTP库Axios
发表于
更新于
本文字数：
1.4k
阅读时长 ≈
2 分钟
本文介绍关于聊聊HTTP库Axios，包括使用场景、实现细节等，以提高关于聊聊HTTP库Axios的效率。
利用工具提升前端代码质量-版本自动化
发表于
更新于
本文字数：
4.3k
阅读时长 ≈
7 分钟
本文介绍关于利用工具提升前端代码质量-版本自动化，包括使用场景、实现细节等，以提高关于利用工具提升前端代码质量-版本自动化的效率。
最近在开发公司的UI组件库，目的是自造轮子，统一公司产品UI，及提升开发效率，不必从零做起。愿景虽美，仍有现实问题，其中就有这样一个点。
库总是需要更新，每次新版本如何发布，目前的操作是每次修改了代码后，提交，同时手动修改版本号，然后执行发布命令，但这样做问题很多，如下。
存在问题
- 每次修改点可能是个
fix，也可能是个feat，又或者修改伴随着breaking change，单从commit信息上，提取不出任何的关键信息，同时，对外没有任何文档输出，假如项目中需要升级包，面对的只是一个个版本号，这样升级起来未免有些提心吊胆。 - 当前版本号的更新全依赖于
人工输入，那么对于版本号的升级就必然出现不规范，不一致的情况，比如一个小的样式BUG的修改，一个新手可能就会直接升级大版本号。这样长此以往就必出问题，更别说手动的输入版本号本身也是个重复的体力劳动。 - 不只是所谓的UI组件库，即使是本身的业务项目，commit message应该是个很好的方式，去描述此次提交的内容，但当前Team中这一环很弱，并且内容简单随意，毫无实际意义。
- 因为
commit的不规范，每次我们提交代码都会出发构建发版，但是实际上，假如只是doc修改，并不一定需要去触发构建发版，而假如想做到能够区分每次commit，那么就需要有规范格式化的commit存在。
以上四点问题支撑我思考，如何利用工具去改善。查阅了相关资料后，发现可以利用成熟化工具解决。
Angular项目参考-优秀样例
前端包发布到npm私服
发表于
更新于
本文字数：
2.4k
阅读时长 ≈
4 分钟
本文介绍关于前端包发布到npm私服，包括使用场景、实现细节等，以提高关于前端包发布到npm私服的效率。
之前Team一直以
Git Submodule的形式共享前端基础模块资源，但存在弊端，于是趁着周末研究下Nexus npm，将前端资源切换到npm形式进行维护管理
Git Submodule的弊端
首先说下使用GitSubmosule形式共享前端包的弊端。
版本管理依赖于commitId，submodule虽然也有分支的概念，但本质依赖于commitID，假如本身的文件存储的就是某个仓库及某次commit。假如在MR代码时，版本不一致，单从这个hash值上，并不知道版本之间，谁是新的。相较npm package的大小版本号就更为浅显易懂些。
子模块的管理方式是将模块的代码全盘拉下，比如UT也会拉下，其实是多余的。
子模块代码在项目中非只读，容易被修改，我希望的是代码保护，只有只读权限