如果做不到固定的开发工作流,确保每一个 MR 都会 review 通过后才会被合并。
那么 OP 你关注于“技术”部分的规范,确实会补充中领导的长远看法一样。
---
关于团队开发规范一般都是开发团队中互相理解认可,最终达成一致的规范。而不是一两个人拍脑袋确定下来的。
至于项目 A 使用,不代表项目 B 也适用。其实和团队 A 认可,不代表团队 B 也会认可一样的。
比如你的举例就很“技术”,并不是一个对于开发流程的规范,更像是 Lint 相关的规范(也就是 Coding Style ),那么确实并不一定适用所有项目。
---
比如你可能会觉得<问题 1>很不爽,但是可能项目开始时期 `script:setup` 并没有实现,所以当时只是使用了 `setup` 并没有使用 `script:setup`。
那么按照你<问题 4>的认定,你多半也不会认可在一个项目中同时出现选项式和组合式两种写法。那么比较合适的情况就是延续旧有的“开发规则”,继续使用 `setup` 开发而不是 `script:setup`,而不是全部重构成 `srcipt:setup`。
至于<问题 2>和<问题 3> 是出于一个中间地带,首先代码量少并不一定就是“好代码”,举个很极端的例子 `const result = condition1 ? condition2 ? 'A' : 'B' : condition3 ? 'C' : 'D';`
虽然示例和 OP 你表达的并不一样,我这样举例有一点抬杠的意味,但想表达的是 代码结构清晰,可以让所有人都可以快速理解的代码,才是真的“好代码”。
不知道你举例的 `useRequest` 是 [VueUse](
https://vueuse.org/core/useFetch/) 这种比较大众的工具类库提供的,还是自己内部实现的工具类库。
API 都声明在一个 `index.js` 文件中,我也觉得会是一个问题,但是可能开发团队已经习惯了直接使用 `import { xx } from '@api' 中引入对应的接口了。
可以贡献一个模块化拆分后 API 维护的 MR ,并且提供和原本一样的聚合后的 `@api/index.js`出口(`export * from './modulesA'`)。
这个 MR 就可以当成首次 review 的一个样例。
---
但是 OP 你得和你的领导确定好,你们想要制定的规范是什么,是开发流程的规范,还是编码风格的规范。
开发流程的规范当形成习惯之后是可以随团队一直延续、传承下去的,但是编码风格的规范会随着不同项目的主导人而不同的。