cuixueshe
[功能] - 统一项目格式化的方案与实现
Description
What
原因：因为项目早期人手不够，大家是主要还是以实现基础功能为主（我们的宗旨：代码能跑就行，谁提需求谁 PR 😄）
所以对于格式化没有过多的关注和要求，目前在项目的 .vscode/settings.json 中配置了一点点关于 prettier 的代码格式化选项，稍微好了一点，但这不是强制的，如果开发者没有安装 prettier 插件，亦或者根本没有使用 VSCode 的情况，那说白了就是摆设 😢
问题：格式化不统一的话，开发时就会出现保存代码后与拉取的代码冲突，最终呢？会让大家提交上来的 PR 出现超级多的 “无效变更”，让贡献者难以 review 代码
从最开始的几个人开发到现在 PR 处理不过来了，贡献者和 star 也越来越多（感谢大家 🙏），说明项目还是蛮有意思能得到大家的认可的，大家才愿意参与进来，所以关于这格式化也是时候好好调整一下了，不然等别人来学习代码时，看到乱七八遭的格式代码，这多不好意思 👀
How
前端后端都需要加上！不过貌似前端和后端使用的格式化规则不太一样~ 可以先做前端的（我非常需要！🤩）
这里有两个相关的 issue
- https://github.com/cuixueshe/earthworm/issues/74
- https://github.com/cuixueshe/earthworm/issues/75
大致意思就是在提交代码的时候需要先通过 更改的文件自动格式化、所有的测试、是否存在打包问题
之前有了解过一点，但是没有深入，可以使用下面的这些工具库方案解决，用于参考
- husky（设置各种 git hook 触发）
- simple-git-hooks （与 husky 选其一即可，貌似更简单一点）
- commitlint（拦截验证失败的 Git 提交）
- ESLint + prettier + lint-staged（校验并辅助格式化代码，需要结合前面几个工具）
嗯……因为并没有深入体验玩过，具体的实现思路和方案我也没有，小嘴一叭只会提建议和要求（逐渐变成自己讨厌的样子，万恶的产品和老板），所以才来新开了 issue 来集思广益，有能力佬们！评论区蹲你们，PR Welcome! 😊
@fengstats Please assign to me.
狠狠的期待住了！
先定个目标，让大家 3步走
- 拉代码
- 推代码
- 提 PR
多一步都是对代码的不尊重🫡
经过和核心开发者讨论后, 计划如下，序号表示优先级。
-
[x] 1. 整个仓库使用 Prettier 规范代码格式，并使用一致的 Prettier 配置，来减少代码一致性问题。降低 PR 的 Review 难度 #375
- [x] 移除子包的 Prettier 和 ESLint 的配置，统一在根目录统一配置
- [x] 迁移 settings.json 的 Prettier 配置 到独立的配置文件
- [x] 使用 ~~Husky~~ simple-git-hooks + pre-commit + lint-staged 强制格式化代码
- [x] vscode 集成
-
[ ] 2. 在提交前运行 test 和 build
- [ ] unit-test
- [ ] e2e-test
- [ ] build
-
[ ] 3. 使用 CI 来运行 unit-test 和 e2e-test
- [ ] unit-test
- [ ] e2e-test
-
[ ] 4. 迁移 ./scripts/verify-commit.ts 到 commitlint
-
[ ] 5. 使用 eslint 规范代码风格