mes接入standard过程记录

Opened this issue 6 years ago · 0 comments

chenyongyang commented 6 years ago

资料

迁移 Javascript Standard Style 总结

安装eslint共享配置
- eslint-config-standard
  - 在eslint中加入standard预设的规则来进行代码检查
- eslint-config-standard-jsx
  - 让standard支持JSX语法，以便检查
- 代码审查发生在开发阶段，因此安装在dev依赖
```
npm install eslint-config-standard eslint-config-standard-jsx -D
```

代码检查的机制是有了，但我们还没有激活它，激活方法是到.eslintrc.js配置，在extends字段引入自定义规则，插件也有这个功能

关于plugins

作用：提供了除 eslint 规定之外额外的规则
插件名一般为 eslint-plugin-xxx，在配置文件中的plugins字段可以缩写为xxx

plugins与extends的区别

extends提供的是eslint现有规则的一系列预设；而plugins则提供了除预设之外的自定义规则
解析器配置
eslint默认采用Espree来解析，我们也可以改为babel-eslint；因为babel-eslint能够让eslint检查更高级的js语法、Flow类型检测等

"parser": "babel-eslint",

根据warn，eslint-config-standard还依赖于一系列eslint-plugin-xxx

npm i eslint-plugin-import eslint-plugin-node eslint-plugin-promise eslint-plugin-standard eslint-plugin-react -D

至此，我们安装了几个依赖，配置文件如下：

module.exports = {
    "parser": "babel-eslint",
    "plugins": [
        "gm"
    ],
    "extends": [
        'standard',
        'standard-jsx'
    ]
};

是否还需要eslint-plugins-gm这个插件呢？定位到它的源码，可以看到它主要定义了环境支持、是否开启某全局变量、解析器选项(支持的语法版本)，修改一些eslint规则；再看到eslint-config-standard，发现其实定义的东西都是差不多的，因此可以把插件去掉，留下standard即可既然已经确定了按照standard的规则来检查代码，那就应该去掉其他规则，只留standard一个就够了，纯粹简单

现在配置文件就是这样

module.exports = {
    "parser": "babel-eslint",
    "extends": [
        'standard',
        'standard-jsx'
    ]
};

至此，eslint standard 配置就暂时告一段落

将整个项目一下子全都检查并修复，这种做法不可取，风险太大

这里是对风险的补充说明：对于一个已经上线、正在提供服务的项目，稳定是最重要的；如果说一下子就把代码全部做迁移，出了错误不好定位，单独把一小块切出来做迁移，可控性更高，差不多跟代码重构一个道理吧

正确做法是把项目按模块划分，单独对每个模块来做迁移，分而治之；lint-staged也是采用分而治之的**，每次是检查git暂存区上的代码，配合husky、pre-commit钩子，就能够很好地实现对每次提交的代码作检查，及时发现并解决问题

npm i lint-staged husky -D

husky的作用：捕捉git钩子，在钩子触发时我们可以做一些工作，如代码检查；配置如下：

"precommit": "lint-staged" // 提交前使用它
"lint-staged": {
  "./js/**/*.js": [
    "eslint --cache --fix", // --cache避免重复检查/--fix尽可能修复能修复的错误
    "git add" 
  ],
  // ...检查其他类型文件
}

编辑器相关

编辑器安装相关插件，方便定位不规范代码；以vscode为例，安装ESlint、StandardJS等插件

自测

让eslint检查并修复小部分模块，跑起来如果无报错，应该就算配置正确了
存在的问题：如果代码前加了修饰器，好像这一行不会被standardjs检查到，如分号没有去掉；解决：修饰器不要和执行代码放在同一行

要兼容webstorm编辑器

闭合标签前的空格问题
standard修复后把所有变量名都改为驼峰写法，但分隔符有时候是必要的
这些都可以通过修改rules来实现兼容

'rules': {
    'react/jsx-tag-spacing': ['error', {'beforeSelfClosing': 'never'}],
    'camelcase': 0
}

库的版本号

自己开发时没太关注依赖库的版本问题，但是作为一个公司的产品，对于任何一个细节都需要谨慎；如果要升级版本，得做好兼容工作

关于git push

如果远程已经存在一个feature-xxx，那本地在作修改之后，想要推到远程，就必须要push -f；否则就会报冲突
遇到冲突要先解决冲突再强推
但是我的操作是通过rebase来合并多个commit，git认为这个也是冲突，这属于和代码无关的冲突，强推即可

关于husky

从0.14版本后升级，配置方面做了一些改动；也就是单独把husky钩子抽离出来

{
  "scripts": {
    // 以前的写法
   "precommit": "npm test",
   "commitmsg": "commitlint -E GIT_PARAMS"
  },
  // 升级后的写法
 "husky": {
   "hooks": {
     "pre-commit": "npm test",
     "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
   }
 }
}