风格指南
一般情况下,采用以下优先顺序:
- 如果各语言/框架/类库自带官方风格指南, 直接遵循官方风格指南
- 如果语言/框架/类库没有官方指南,如
react
, 尽量挑选开源社区比较成熟的方案使用,比如 airbnb 的规则 - 如果业务需要,可以在上述基础上进行对应自定义覆写
JavaScript 及 Vue
目前公司为 Vue 技术栈,直接使用官方推荐配置即可。
Vue 2
Vue-cli
中包含了 airbnb 的 JavaScript 校验,及 自带的 Style Guild。
{
extends: [
'plugin:vue/recommended',
'@vue/airbnb',
],
}
Vue 3
create-vue
中包含了一套 TypeScript 校验规则、esLint 自带的推荐规则、以及 Vue 3 的 Style Guild。
{
'extends': [
'plugin:vue/vue3-recommended',
'eslint:recommended',
'@vue/eslint-config-typescript/recommended'
],
}
目前,已经把上述规则整合进了公共包 @seemusic/eslint-config-vue3,跨项目 推荐 直接使用公共包,保持规则统一。
自定义
实际开发中,会根据需求自定义一些 eslint 的规则,比如最常见的两个:
{
'vue/no-v-html': 'off',
'vue/multi-word-component-names': ['error', {
'ignores': [
'Home',
'Overview',
]
}]
}
调试的时候,可以使用
eslint --print-config ./eslintrc.cjs | pbcopy
的命令,把当前 eslintrc 文件产生的最终配置复制到剪切板
不要滥用自定义规则
需要注意的是,自定义规则仅出于满足业务需要进行覆写,不要 利用自定义规则规避校验。
实际场景中,会在特定时期使用过渡方案,比如对陈旧项目进行 TypeScript
重构,会允许使用 any
。项目中保留 no-explicit-any 的规则,给出 warning
级别的提示,会方便日后进行代码优化。
CSS
公司项目大多使用 SCSS
,且没有对格式、实现方式进行约束。
关于 Prettier
不建议 在团队层面强制使用 Prettier。
社区中有不少这方面的讨论,比如
如果个人使用,需要设置好 .gitignore
文件:
- 禁止 把个人的 Prettier 配置文件提交到公共代码仓库
- 禁止 轻易对 已有 的运行在生产环境中的代码随意进行格式化