过去两个月没碰这个项目，再次打开这个项目发现很多我之前写的文件报类型错误，本文在此记录一下寻找问题的过程。
一、问题描述
今天再次打开2个月之前写的代码发现很多类型报错：
我敢确定当初写代码的时候一定没有报错，否则我一定会解决。那么问题出在哪里呢？
二、排查过程
1. 发现多余的lock文件
我们项目一直用的是pnpm，只会有pnpm-lock.json。但是发现现在有新的package-lock.json：
我的代码是在1月5号写的：
而同事的package-lock.json文件是在1月11号提交的：
不同版本的eslint或者周边依赖，校验规则可能不同。虽然理论上来说，同事只提交了package-lock.json文件，我本地后续如果没有执行npm install的话，node_modules文件夹就不会更新，eslint版本也就不会变更。但是为了排除这个原因，我还是得删除node_modules文件夹（顺便删除一下多余package-lock.json），然后再pnpm install。
emmm....
不出所料，问题依旧。
但为了确保同事不再使用 npm 安装，我需要做一些限制：
首先，readme中补充说明比如使用 pnpm：
md
### 开发环境设置
本项目使用 pnpm 作为包管理工具。请不要使用 npm 或 yarn 安装依赖。然后，需要做硬性限制： 在.npmrc 文件中添加：
text
engine-strict=true再在package.json中添加：
json
"engines": {
"node": ">=14", // 这里我并不确定具体的有效范围，但本次的目的只是限制非pnpm的包管理工具，所以设置了大范围
"npm": "please-use-pnpm",
"yarn": "please-use-pnpm",
"pnpm": ">=6" // 这里也一样
}npm install 测试一下：
配置生效。
但还需要继续排查问题...
2. eslint 配置文件有改动？
格式校验是来自于eslint，eslint扩展会读取本项目的eslint配置来检查代码格式问题。
检查一下项目根目录的.eslintrc.cjs 的file history，看是否有改动：
其中最上面我的改动只是：
和剩下很多报错没有关系。所以没有人进行eslint配置调整。
3. eslint扩展版本问题？
那有没有可能是扩展的版本问题？
发现扩展的版本更新是更早之前，所以也排除。
4. 当你排除了所有的不可能性，剩下的无论多不可能都是真相------------我当时敲代码的时候没有下载ESLint扩展
那么剩下或许只有这一种可能，就是当时敲代码的时候没有ESLint扩展。没有ESLint扩展自然不会去进行格式校验。
禁用ESLint后也确实如此。
自言自语
当时可能我在vscode和cursor之间反复横跳，忘记下载扩展？那会cursor很火，我不断得尝试新账号去试用cursor的ai功能，试用结束后又回到vscode，然后听说有换机器码的脚本来无限续杯cursor，然后又下载...但cursor在下载后会自动导入vscode配置和扩展的呀...但不管怎么说这或许是最有可能的答案了...
根据ESlint规则设置的.prettierrc.json格式化为什么不生效？
话又说回来，即使当时没有ESLint扩展来校验，但是我看根目录有.prettierrc.json：
如果根据这个配置格式化，起码能够避免tab缩进问题：
编辑器对文件格式化的规则
要知道原因，肯定得了解编辑器对文件格式化的规则：
项目级别设置 --> 工作区级别设置 --> 用户级别设置 --> 系统级别设置
排查：
检查项目根目录的.vscode文件夹下的 setting.json配置，看看对应文件的格式工具配置：
发现根本没有配置！再检查用户级别（ctrl+shit+p 输入setting 选择用户设置）：
编辑器的用户级别设置对VUE文件的格式化工具设置的是...Volar，而不是 prettier。
正常来说，我们搭建项目要在项目根目录的.vscode --> setting.json 文件指定对应的格式化工具（还有项目所用到的vscode扩展等等）为了确保所有协作开发者的风格保持一致。
所以我们需要添加：
diff
{
"i18n-ally.localesPaths": [
"src/lang"
],
+ "[vue]": {
+ "editor.defaultFormatter": "esbenp.prettier-vscode"
+ },
}那么是否应该将.vscode -> setting.json 提交到代码仓库呢（各有利弊）？
可以看到，项目创建者在最早是将它屏蔽了的。一般大型的开源项目肯定是会提交到git仓库的，但这里我就解决我自己的问题就好了，尊重团队的决策。
总结
当你排除了所有的不可能性，剩下的无论多不可能都是真相 ------------ 我当时没有下载ESLint扩展，同时项目的setting文件也没有指定代码格式化工具。两个原因共同导致了我写了不符合格式规范的代码，并提交到git仓库。 当然提交时也可以通过 lint-staged来进行格式化检查，本篇就不赘述了。