package-lock.json含async但package.json未声明的ESLint报错咨询

• Node.js的模块解析逻辑是从当前文件所在目录开始，逐层向上查找node_modules目录下的对应包；而npm、yarn等包管理器默认会做依赖提升：如果多个包依赖同一个第三方库，会尽量把这个库放到项目根目录的node_modules下减少重复安装。你项目里的async就是某个你直接安装的依赖所依赖的传递依赖，被提升到了根目录，所以你代码里引入async的时候Node能正常找到包，运行不会报错。
• package-lock.json会记录项目依赖树上所有包的版本、下载地址、依赖关系，不管是你手动声明的直接依赖，还是层层嵌套的传递依赖都会被记录，所以能在lock文件里找到async完全不代表它是你项目的直接依赖。
• 触发报错的是ESLint的import/no-extraneous-dependencies规则，这个规则不会判断你能不能蹭到node_modules里的传递依赖，只会校验你代码中引入的包是否在package.json的依赖字段（dependencies/devDependencies/peerDependencies）中显式声明，所以会抛出提示。

这种“蹭传递依赖”的写法非常不可靠：

• 传递依赖的版本、存在性完全不受你控制：如果后续你升级了那个依赖async的直接依赖，对方可能移除async依赖、更换大版本、或者调整依赖结构导致async不再被提升到根目录，你的项目会直接抛出Cannot find module 'async'的运行时错误。
• 不同包管理器、甚至同包管理器的不同大版本的依赖提升逻辑存在差异，本地能正常运行的代码，在CI环境、其他同事的设备上可能装完依赖直接跑不起来。

• 如果你代码里确实主动引入使用了async：直接在项目根目录执行安装命令把它加到显式依赖里即可，对应命令参考：
  • npm用户执行：npm install async
  • yarn用户执行：yarn add async
  • pnpm用户执行：pnpm add async
    安装完成后package.json的dependencies字段会自动加上async的版本声明，ESLint报错会直接消失，也能彻底消除蹭依赖的隐患。
• 如果你全局搜索代码后确认没有主动引入async：优先排查是不是有无效的残留引入语句没删，删掉即可；如果是第三方包内部逻辑触发的ESLint误判，可以在ESLint配置文件中针对对应场景调整规则，不过这类情况出现概率极低。

内容的提问来源于stack exchange，提问作者Tal Wind