[功能] - 统一项目格式化的方案与实现

[fengstats]

Description

What

原因：因为项目早期人手不够，大家是主要还是以实现基础功能为主（我们的宗旨：代码能跑就行，谁提需求谁 PR 😄）

所以对于格式化没有过多的关注和要求，目前在项目的 .vscode/settings.json 中配置了一点点关于 prettier 的代码格式化选项，稍微好了一点，但这不是强制的，如果开发者没有安装 prettier 插件，亦或者根本没有使用 VSCode 的情况，那说白了就是摆设 😢

问题：格式化不统一的话，开发时就会出现保存代码后与拉取的代码冲突，最终呢？会让大家提交上来的 PR 出现超级多的 “无效变更”，让贡献者难以 review 代码

从最开始的几个人开发到现在 PR 处理不过来了，贡献者和 star 也越来越多（感谢大家 🙏），说明项目还是蛮有意思能得到大家的认可的，大家才愿意参与进来，所以关于这格式化也是时候好好调整一下了，不然等别人来学习代码时，看到乱七八遭的格式代码，这多不好意思 👀

How

前端后端都需要加上！不过貌似前端和后端使用的格式化规则不太一样~ 可以先做前端的（我非常需要！🤩）

这里有两个相关的 issue

• 在 git push 之前执行 test&lint&build #74
• 添加 CI 执行 test&eslint&build #75

大致意思就是在提交代码的时候需要先通过 更改的文件自动格式化、所有的测试、是否存在打包问题

之前有了解过一点，但是没有深入，可以使用下面的这些工具库方案解决，用于参考

• husky（设置各种 git hook 触发）
• simple-git-hooks （与 husky 选其一即可，貌似更简单一点）
• commitlint（拦截验证失败的 Git 提交）
• ESLint + prettier + lint-staged（校验并辅助格式化代码，需要结合前面几个工具）

嗯……因为并没有深入体验玩过，具体的实现思路和方案我也没有，小嘴一叭只会提建议和要求（逐渐变成自己讨厌的样子，万恶的产品和老板），所以才来新开了 issue 来集思广益，有能力佬们！评论区蹲你们，PR Welcome! 😊

[baboon-king]

@fengstats
Please assign to me.

[fengstats]

@fengstats Please assign to me.

狠狠的期待住了！

[baboon-king]

@fengstats Please assign to me.

狠狠的期待住了！

先定个目标，让大家 3步走

1. 拉代码
2. 推代码
3. 提 PR

多一步都是对代码的不尊重🫡

[zuowendong]

目前项目中实现的git hooks方案是采用 simple-git-hooks，集成了对commit-msg的校验

[cuixiaorui]

在 pre-commit 阶段做 lint
参考 vue3 的做法

[cuixiaorui]

ci 也需要加上
参考 vue3 的实现

[baboon-king]

经过和核心开发者讨论后, 计划如下，序号表示优先级。

• 1. 整个仓库使用 Prettier 规范代码格式，并使用一致的 Prettier 配置，来减少代码一致性问题。降低 PR 的 Review 难度 chore: setup Prettier to keep code format Style #375

  • 移除子包的 Prettier 和 ESLint 的配置，统一在根目录统一配置
  • 迁移 settings.json 的 Prettier 配置 到独立的配置文件
  • 使用 Husky simple-git-hooks + pre-commit + lint-staged 强制格式化代码
  • 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 规范代码风格