Why: 给项目添加eslint和prettier,本来以为就是一件手到擒来的事情,直到那个人出现...
How: 老项目使用webpack5, eslint@8,如果一切顺利,我要做的就是
- 添加husky,在commit时执行eslint的类型校验,
eslint . --ext .js,.ts,.tsx - 添加项目级别的vscode设置
.vosde/settings.json,保存时触发格式化,自动修复等等
以前的项目, tsconfig noImplicitAny:false, 表示 ts能力是可选的,因此很多错误都不会提示,现在改成 noImplicitAny:true, 编辑器立即出现一个错误提示, demo
先不解决它, 执行 pnpm run lint, 发现eslint没有报告这个错误,
其实在 pnpm run lint之前, 我们就能知道结果了, 正常情况下, 鼠标hover上去,ts和eslint都会报告一次错误
得出结论, eslint的类型校验不可靠,生产环境,还是得使用ts官方的工具 tsc 来做校验
同理 开发组件库,生成类型文件时,最好也使用tsc,不要用其他插件, 比如 rollup-typescript2
那么,我们还有必要使用 eslint 吗? eslint除了做语法检查,还有就是代码写法优化, 以前还有个格式化风格,现在已经没有了, 我觉得作用越来越弱, 我打算试试新出的oxlint, 两方面原因:
- eslint@9 上个月刚发布,在webpack5里使用,初始化得到的是.mjs, webpack好像不是很支持,以及import is reserved 的报错, 一时解决不了,感觉还是vite好, 懒得花给他们做测试
- oxlint的两个好处是:快,有好的提示, 不是很需要,只在commit时执行eslint,或者vscode当前文件, 文件内容少,速度无感知的,至于友好的提示,对于我来说比较鸡肋,聊胜于无吧,因为这东西只在开发时使用, 不会影响业务代码稳定性, 所以体验下还是可以的 一些顾虑点(硬核需求): react的hook deps辅助的eslint插件,是否支持
基于越简单越好的原则, 本想找出所有的eslint错误,手动修复,但是执行pnpm run build, 只会碰到一个错误就中断了, 而且build很久, 执行 pnpm run start, 会打印所有错误,试着排查一下发现给出的全是ts的错误,而不是eslint的, 不知道webpack内部怎么跑的, 还是觉得vite好,一个插件做一件事情,排查问题起来很简单, 积累经验以后,知道每个插件的功能, 对于开发rollup也很有帮助, 后来, 尝试使用 tsc --noEmit 来找错误, 但是报了其他错误就中断了, webpack真tm的黑盒: ts官方的tsc都跑不起来的, 你怎么跑通的? 只想说别搞我
文章到这里也差不多了, 最后给出我对于eslint如何在项目里使用的心得
使用 husky + lint-staged, 在pre-commig阶段,使用eslint做校验, 在pre-push阶段,使用tsc --noEmit做校验
其他:
选择包管理器以及node版本,需要考虑的问题, 以及如何在ci jenkis里使用volta,nvm?
- react-native对于pnpm支持度不是很好, 特别是expo, 业务代码总是会被转为cjs, esm和cjs转来转去,就会出现一些问题, 比如:github.com/magicismigh…, 所以官方提供的好像是yarn, 当然能一步步解决pnpm带来的问题,坚持使用pnpm更好,得多烧香拜佛
- 对于线上build来说,需要考虑线上的环境,有些服务器降老旧, 没有新的node版本, 所以得检查你的pnpm需要的最低node版本是否已达到, 此外服务器是否安装了nvm, volta等,如果没有,那么在ci里得执行安装命令
