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
对于Typescript项目的编码规范而言,主要有两种选择ESLint和TSLint。ESLint不仅能规范js代码,通过配置解析器,也能规范TS代码。此外由于性能问题,TypeScript 官方决定全面采用ESLint,甚至把仓库作为测试平台,而 ESLint 的 TypeScript 解析器也成为独立项目,专注解决双方兼容性问题。 最近在我的项目的编码规范中全量的用ESLint代替了TSLint,针对其中遇到的问题做一个记录。
用ESLint来规范Typescript代码 用ESLint来规范React代码 结合Prettier和ESLint来规范代码 在VSCode中使用ESLint husky和lint-staged构建代码工作流 gitlab的CI/CD来规范代码
首先安装依赖:
npm i -d eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
这三个依赖分别是:
安装好这3个依赖包之后,在根目录下新建.eslintrc.js文件,该文件中定义了ESLint的基础配置,一个最为简单的配置如下所示:
module.exports = { parser: '@typescript-eslint/parser', //定义ESLint的解析器 extends: ['plugin:@typescript-eslint/recommended'],//定义文件继承的子规范 plugins: ['@typescript-eslint'],//定义了该eslint文件所依赖的插件 env:{ //指定代码的运行环境 browser: true, node: true, } }
如果在你的TS项目中同时使用了React,那么为了检测和规范React代码的书写必须安装插件eslint-plugin-react,然后增加配置:
module.exports = { parser: '@typescript-eslint/parser', extends: [ 'plugin:react/recommended' 'plugin:@typescript-eslint/recommended' ], //使用推荐的React代码检测规范 plugins: ['@typescript-eslint'], env:{ browser: true, node: true, }, settings: { //自动发现React的版本,从而进行规范react代码 "react": { "pragma": "React", "version": "detect" } }, parserOptions: { //指定ESLint可以解析JSX语法 "ecmaVersion": 2019, "sourceType": 'module', "ecmaFeatures":{ jsx:true } } rules: { } }
在Rules中可以自定义你的React代码编码规范。
Prettier中文的意思是漂亮的、美丽的,是一个流行的代码格式化的工具,我们来看如何结合ESLint来使用。首先我们需要安装三个依赖:
npm i -g prettier eslint-config-prettier eslint-plugin-prettier
其中:
然后在项目的根目录下创建.prettierrc.js文件:
module.exports = { "printWidth": 120, "semi": false, "singleQuote": true, "trailingComma": "all", "bracketSpacing": false, "jsxBracketSameLine": true, "arrowParens": "avoid", "insertPragma": true, "tabWidth": 4, "useTabs": false };
接着修改.eslintrc.js文件,引入prettier:
module.exports = { parser: '@typescript-eslint/parser', extends:[ 'prettier/@typescript-eslint', 'plugin:prettier/recommended' ], settings: { "react": { "pragma": "React", "version": "detect" } }, parserOptions: { "ecmaVersion": 2019, "sourceType": 'module', "ecmaFeatures":{ jsx:true } }, env:{ browser: true, node: true, }
上述新增的extends的配置中:
为了开发方便我们可以在VSCode中集成ESLint的配置,使得代码在保存或者代码变动的时候自动进行ESLint的fix过程。
首先需要安装VSCode的ESLint插件,安装插件完毕后,在settings.json文件中修改其配置文件为:
{ "eslint.enable": true, //是否开启vscode的eslint "eslint.autoFixOnSave": true, //是否在保存的时候自动fix eslint "eslint.options": { //指定vscode的eslint所处理的文件的后缀 "extensions": [ ".js", ".vue", ".ts", ".tsx" ] }, "eslint.validate": [ //确定校验准则 "javascript", "javascriptreact", { "language": "html", "autoFix": true }, { "language": "vue", "autoFix": true }, { "language": "typescript", "autoFix": true }, { "language": "typescriptreact", "autoFix": true } ] }
主要注意的有两点:
首先来看husky,Husky 能够帮你阻挡住不好的代码提交和推送,首先我们在package.json中定义如下的script:
"scripts": { "lint": "eslint src --fix --ext .ts,.tsx " }
接着在package.json定义husky的配置:
"husky": { "hooks": { "pre-commit": "npm run lint" } },
我们在git的hook的阶段来执行相应的命令,比如上述的例子是在pre-commit这个hook也就是在提交之前进行lint的检测。
接着来看lint-staged,上述我们通过在husky的pre-comit这个hook中执行一个npm命令来做lint校验。除了定义个npm lint命令外,我们也可以直接通过使用lint-staged,来在提交前检测代码的规范。 使用lint-staged来规范代码的方式如下,我们修改package.json文件为:
{ "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.{.ts,.tsx}": [ "eslint", "git add" ] } }
同样在git commit的时候会做lint的检测。
仅仅通过git的hook来执行代码的规范检测有一个问题,我们可以在git commit的时候通过--no-verify来跳过代码的规范检测。但是某些情况下,我们对于某一个重要分支,该分支上的代码必须完整通过代码的规范检测,此时我们可以使用gitlab的CI/CD。
同样在package.json中增加一个lint的npm 命令:
然后在根目录增加.gitlab-ci.yml文件,该文件中的配置为:
stages: - lint before_script: - git fetch --all - npm install lint: stage: lint script: - npm run lint only - 特定分支1 - 特定分支2
然后配置相应的gitlab runner,这里不具体详描,最后的结果就是在我们指定的分支上的提交或者merge都会进行所配置的命令检测。这样保证了特定分支不受git commit跳过操作--no-verify的影响。
The text was updated successfully, but these errors were encountered:
使用了Prettier就不需要再配置eslint的rules了吗
Sorry, something went wrong.
当然不是,prettier仅仅是代码缩进等格式
prettier 仅仅是格式化代码,和 editorconfig 是一种类型,不过 editorconfig 是和你的IDE绑定以插件形式修改代码。prettier 先进一点,和项目绑定。
eslint 就不一样了,能 check 你的代码风格和简单的错误,比如 no-console 这种。
No branches or pull requests
对于Typescript项目的编码规范而言,主要有两种选择ESLint和TSLint。ESLint不仅能规范js代码,通过配置解析器,也能规范TS代码。此外由于性能问题,TypeScript 官方决定全面采用ESLint,甚至把仓库作为测试平台,而 ESLint 的 TypeScript 解析器也成为独立项目,专注解决双方兼容性问题。
最近在我的项目的编码规范中全量的用ESLint代替了TSLint,针对其中遇到的问题做一个记录。
一、用ESLint来规范Typescript代码
首先安装依赖:
这三个依赖分别是:
安装好这3个依赖包之后,在根目录下新建.eslintrc.js文件,该文件中定义了ESLint的基础配置,一个最为简单的配置如下所示:
二、用ESLint来规范React代码
如果在你的TS项目中同时使用了React,那么为了检测和规范React代码的书写必须安装插件eslint-plugin-react,然后增加配置:
在Rules中可以自定义你的React代码编码规范。
三、结合Prettier和ESLint来规范代码
Prettier中文的意思是漂亮的、美丽的,是一个流行的代码格式化的工具,我们来看如何结合ESLint来使用。首先我们需要安装三个依赖:
其中:
然后在项目的根目录下创建.prettierrc.js文件:
接着修改.eslintrc.js文件,引入prettier:
上述新增的extends的配置中:
四、在VSCode中集成ESLint配置
为了开发方便我们可以在VSCode中集成ESLint的配置,使得代码在保存或者代码变动的时候自动进行ESLint的fix过程。
首先需要安装VSCode的ESLint插件,安装插件完毕后,在settings.json文件中修改其配置文件为:
主要注意的有两点:
五、husky和lint-staged构建代码工作流
首先来看husky,Husky 能够帮你阻挡住不好的代码提交和推送,首先我们在package.json中定义如下的script:
接着在package.json定义husky的配置:
我们在git的hook的阶段来执行相应的命令,比如上述的例子是在pre-commit这个hook也就是在提交之前进行lint的检测。
接着来看lint-staged,上述我们通过在husky的pre-comit这个hook中执行一个npm命令来做lint校验。除了定义个npm lint命令外,我们也可以直接通过使用lint-staged,来在提交前检测代码的规范。
使用lint-staged来规范代码的方式如下,我们修改package.json文件为:
同样在git commit的时候会做lint的检测。
六、gitlab的CI/CD来规范代码
仅仅通过git的hook来执行代码的规范检测有一个问题,我们可以在git commit的时候通过--no-verify来跳过代码的规范检测。但是某些情况下,我们对于某一个重要分支,该分支上的代码必须完整通过代码的规范检测,此时我们可以使用gitlab的CI/CD。
同样在package.json中增加一个lint的npm 命令:
然后在根目录增加.gitlab-ci.yml文件,该文件中的配置为:
然后配置相应的gitlab runner,这里不具体详描,最后的结果就是在我们指定的分支上的提交或者merge都会进行所配置的命令检测。这样保证了特定分支不受git commit跳过操作--no-verify的影响。
The text was updated successfully, but these errors were encountered: