写了一份前端 Linter 的总结教程

好东西 谢谢分享 以前每次从零开始做基建搞这玩意是真的痛苦，每次都得从头查

不错不错。

其实还行吧. 设置 vsc 的快捷键用 prettier 格式化一下(我的是 vue 的, 不知道其他两大框架行不行), 然后设置 vsc 的保存动作 调 eslint 格式化当前文件, 这样就很快乐了.

@defunct9

@TomatoYuyuko 这些小工具是很蛋疼

写的真好，谢谢分享~ 前端的东西太多太复杂了且各自为战=。= 希望以后有机会能看到作者写的前端其他方面的这种小书
喜欢 Opinionated

@wu67 现在的 IDE 和 vscode 都集成得很好了，这里主要是梳理一下这些工具之间的关系~

@datian9966 thx

呃，eslinit 有 --init 吧，没必要从 0 开始创建 .eslintrc 吧

看完了，很清楚，不过我感觉下次建项目还是会忘。。

第二个问题的解决方法:

https://github.com/unlight/eslint-plugin-tsc

"*.ts": "eslint --max-warnings=0 --plugin tsc --rule 'tsc/config: [2, {configFile: \"./tsconfig.json\"}]'",

linter 千万不要做格式相关事情，那个全交给 prettier 就行了，否则性能不好，开发体验也不好。
直接设置 vscode 保存时调 prettier 格式化是最优做法。

@makelove linter 能格式化的东西可比 prettier 多。可以包含 prettier 的规则

@makelove 我刚开始也是这么想的，不过 eslint x prettier 可在 IDE 里直接有提示自动修复还是挺好的，而且也能自动有报错提示，不跑 eslint --fix 其实还好~

@Trim21 哦，把这玩意忘了，看 Issue 的时候是看过，当时看这 Github star 太少了，感觉不是很官方就给忘了，回头试试

@shyling 是的，这些配置都可以用 --init 来初始化，这里主要是不想写太多干扰项~以及方便引出后续~

eslint fix 能做的东西虽然更多，但是在我看来略带 “危险”
它可以静默更改约定的 eslint fix code 方法是插件实现的。

我的工作流是 save 的时候 prettier , pre-commit eslint 检测。

但是我如今配 vue 的时候，vue sfc 还是很难配。因为我期望是渐进式的，同时支持 vue3 + js 或者 vue3 + ts ，并且支持不同的 lint rules 。
但是我目前仍未有很好的解决方式。

放弃这些就好了.

@connection 这里你说的 pre-commit eslint 检测是指不用 prettier 插件来 fix 么？但是如果这样的话，就用不了 prettier/prettier 规则了，在 IDE 不会报错诶

的

点赞，完全命中我的困扰

当你熟读这些个格式规则烂熟于心并能做到兼收并蓄之后，你会发现你的项目进度已经接近 deadline ，而项目经理完全不屑你搞的这些劳什子。

@robinlovemaggie 所以我才把它们都总结起来，方便其它人可以在 ddl 前搞完项目

我进来是要喷规则的，LZ 你在规则上竟然不站队，太不男人了，shame on you.

我想说的是，prettier 懂个屁，已禁。

airbnb 规则蠢就算了，邪说还舔脸放出来，天灭 airbnb, 壮哉我大 Covid, 坐等你家倒闭。

最后一条，分号不是给编译器看的，是给程序员潜意识降低心智负担的，谁不写分号还拒绝归化的，立刻

@Haixiang 我的是 eslint 仅仅用来 check ，不使用它的 fix.

期待 eslint-plugin-import 的配置，配置一次恶心一次

写的真好 收藏收藏

prettier 格式化的时候某些地方会多一些 ;;; 有没有大佬遇到过

@kensoz

@kensoz 还有这玩意，我研究研究

@a1248499257 这倒是没有，可以给 eslint-plugin-prettier 提个 Issue

@kensoz 看了一下主要是支持 import/export 语法的吧，这个如果用 TS 的话，可以用 TypeScript 的 Parser 解决，如果写 JS 一般也可以用 Babel Parser 解决。

@Haixiang 老早之前就有人提了，open 了好几年没解决

@Haixiang
是，就是检查 import/export ，貌似国内用的不多
一般的导入导出检查 ts 就可以了，适用于需要自定义的场合
下面这是我的 lint 全家福（ react 开发）
"devDependencies": {
"@typescript-eslint/eslint-plugin": "^5.9.1",
"@typescript-eslint/parser": "^5.9.1",
"eslint": "^8.6.0",
"eslint-config-airbnb": "^19.0.4",
"eslint-config-prettier": "^8.3.0",
"eslint-plugin-html": "^6.2.0",
"eslint-plugin-import": "^2.25.4",
"eslint-plugin-jsx-a11y": "^6.5.1",
"eslint-plugin-react": "^7.28.0",
"eslint-plugin-react-hooks": "^4.3.0",
"prettier": "^2.5.1"
}

我现在有时间也会研究 lint ，目前有这么几个课题
1.react 开发只配置过 airbnb ，上面这套就是 airbnb 的常用配置，不知道 Google 和 Standard 是怎么配置
2.vue 开发纯复制粘贴老项目的，没用过 eslint init
3.extends 和 plugins 的区别
4."prettier"到底写在哪里

lint 的坑太多了

@kensoz 说下我自己的理解哈：
1. 这个应该查一下 eslint-config-google , eslint-config-standard ，然后 extends 一下就好了, eslint-config-xxx 就是 xxx 的规则集
2. vue 的规则比 react 感觉简单很多，eslint-plugin-vue 就搞定了，除了可以识别 .vue 文件，还有自己一些规则
3. extends 一般是 extends 规则，但是也可以作为一些配置“缩写”的方式，可以参考 eslint-config-prettier 的配置，plugins 一般是用来识别不同的框架、文件下缀的，比如 eslint-plugin-vue, eslint-plugin-react 。这里和 Parser 又是不一回事，像我们用到的 Parser ，eslint 本身就自带了一个 ES 的 Parser ，TypeScript 还有自己的 parser ，Babel 也有对应的 ESLint Parser
4. prettier 作为规则是要写成 'prettier/prettier': 'error'
如果你用 typescript 的 parser 来解析 TS 文件，其实 jsx, react, import/export, es6 这些语法都能通过 tsconfig.json 来配置识别，可以不需要重复的 esling-plugin-xxx

没那么多条条框框。统一用 standardJS, 保存后 ALE 后台自动执行格式化、Fix

@Haixiang
给力老哥，我先研究一下，你这么一说我又想折腾折腾了

@Haixiang
关于第四条，4."prettier"到底写在哪里
是因为有很多网上的教程不仅把 prettier 写到 plugins 里
还经常以 plugins/prettier... 的形式写到 extend 里，有点头大
在怀疑是不是和 prettier 版本有关

```
{
"extends": ["plugin:prettier/recommended"]
}
```
是下面的缩写
```
{
"extends": ["prettier"],
"plugins": ["prettier"],
"rules": {
"prettier/prettier": "error",
"arrow-body-style": "off",
"prefer-arrow-callback": "off"
}
}
```
大概就是总让人困惑的原因吧, https://github.com/prettier/eslint-plugin-prettier#recommended-configuration

厉害，第一次这么全的了解 lint ，不过我挺不喜欢用 eslint 的，语法问题现在的 IDE 都提示的挺好了，格式化代码用 prettier 是真香，但是挺多同事不知道这个，老项目也没法改

@Haixiang 可以看看 https://github.com/prettier/eslint-plugin-prettier Github 的 Exactly what does plugin:prettier/recommended do? Well, this is what it expands to: 这里

@xujiahui eslint 主要还是团队内一些规则约定吧，不能保证所有人的 IDE 都能这么智能地提示

@Haixiang 现在前端 IDE 基本就 WebStorm 和 VSCode 了吧，eslint 本身配置项太多太麻烦，有时候临时写的调试代码还会触发 error ，得用注释禁用 eslint ，就感觉挺烦的

有没有那种一键配置好的，真不想配这玩意，太费劲啦

@Ritr 这也是我觉得很痛苦的一点，前端的工具除了要各自为战，还有一个原因是前端发展太快了，时不时出新东西，后面的工具就像打补丁一样，要么出 NPM 包，要么自身的 Issue 没解决完

最近在设计前端团队协作规范，巧合看到了 OP 的帖子，非常有用，感谢分享

@GeekJason