Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mes接入standard过程记录 #52

Open
chenyongyang opened this issue Oct 24, 2018 · 0 comments
Open

mes接入standard过程记录 #52

chenyongyang opened this issue Oct 24, 2018 · 0 comments

Comments

@chenyongyang
Copy link

chenyongyang commented Oct 24, 2018

资料

迁移 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"
   }
 }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant