We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
迁移 Javascript Standard Style 总结
npm install eslint-config-standard eslint-config-standard-jsx -D
代码检查的机制是有了,但我们还没有激活它,激活方法是到.eslintrc.js配置,在extends字段引入自定义规则,插件也有这个功能
关于plugins
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" ], // ...检查其他类型文件 }
编辑器相关
自测
要兼容webstorm编辑器
'rules': { 'react/jsx-tag-spacing': ['error', {'beforeSelfClosing': 'never'}], 'camelcase': 0 }
库的版本号
关于git push
关于husky
{ "scripts": { // 以前的写法 "precommit": "npm test", "commitmsg": "commitlint -E GIT_PARAMS" }, // 升级后的写法 "husky": { "hooks": { "pre-commit": "npm test", "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" } } }
The text was updated successfully, but these errors were encountered:
No branches or pull requests
资料
迁移 Javascript Standard Style 总结
代码检查的机制是有了,但我们还没有激活它,激活方法是到.eslintrc.js配置,在extends字段引入自定义规则,插件也有这个功能
关于plugins
plugins与extends的区别
extends提供的是eslint现有规则的一系列预设;而plugins则提供了除预设之外的自定义规则
解析器配置
eslint默认采用Espree来解析,我们也可以改为babel-eslint;因为babel-eslint能够让eslint检查更高级的js语法、Flow类型检测等
根据warn,eslint-config-standard还依赖于一系列eslint-plugin-xxx
至此,我们安装了几个依赖,配置文件如下:
是否还需要eslint-plugins-gm这个插件呢?
定位到它的源码,可以看到它主要定义了环境支持、是否开启某全局变量、解析器选项(支持的语法版本),修改一些eslint规则;再看到eslint-config-standard,发现其实定义的东西都是差不多的,因此可以把插件去掉,留下standard即可既然已经确定了按照standard的规则来检查代码,那就应该去掉其他规则,只留standard一个就够了,纯粹简单现在配置文件就是这样
至此,eslint standard 配置就暂时告一段落
将整个项目一下子全都检查并修复,这种做法不可取,风险太大
这里是对风险的补充说明:对于一个已经上线、正在提供服务的项目,稳定是最重要的;如果说一下子就把代码全部做迁移,出了错误不好定位,单独把一小块切出来做迁移,可控性更高,差不多跟代码重构一个道理吧
正确做法是把项目按模块划分,单独对每个模块来做迁移,分而治之;lint-staged也是采用分而治之的思想,每次是检查git暂存区上的代码,配合husky、pre-commit钩子,就能够很好地实现对每次提交的代码作检查,及时发现并解决问题
husky的作用:捕捉git钩子,在钩子触发时我们可以做一些工作,如代码检查;配置如下:
编辑器相关
自测
要兼容webstorm编辑器
库的版本号
关于git push
关于husky
The text was updated successfully, but these errors were encountered: