Webpack项目中npm link共享common模块的依赖配置问题咨询

我来帮你梳理这个问题——这本质是npm link的模块解析逻辑和Webpack默认模块查找策略的冲突，再加上多模块间重复依赖common导致的代码实例不一致问题。下面分点给你解决思路：

1. 为什么npm link后子模块无法访问common？ #

当你在main-project执行npm link common时，主项目的common会指向本地开发版本，但alfa、bravo如果自身node_modules里有common（或是它们自己也link了common），Webpack会优先加载子模块自身目录下的common——这是因为Node.js和Webpack的模块解析默认是从当前模块目录向上递归查找，子模块的node_modules会被优先命中，最终导致多个common实例共存，进而出现“无法访问代码”的问题（比如导出不匹配、类型校验失败等）。

而当你用版本号引用时，npm会自动把alfa、bravo的common依赖扁平化到主项目的node_modules里，所有模块共用同一个common，所以运行正常。

2. Webpack配置调整：强制全局使用同一个common #

要让主项目link的common覆盖所有子模块的引用，你需要修改Webpack的resolve.alias配置，强制所有模块解析common时都指向主项目中的link版本：

在main-project的webpack配置文件中添加：

const path = require('path');

module.exports = {
  // ...其他配置项
  resolve: {
    alias: {
      // 强制所有对'common'的require/import都指向主项目node_modules里的link版本
      'common': path.resolve(__dirname, 'node_modules/common')
    }
  }
};

这样不管是主项目还是子模块里的require('common')，都会被Webpack解析为主项目中link的common，确保全局只有一个版本。

如果你的子模块也有独立的Webpack配置（比如它们是可单独打包的模块），你需要在子模块的配置里也添加同样的alias，或者通过环境变量动态设置路径，确保所有模块指向同一个本地common。

3. 依赖类型优化：改用peer依赖 #

非常推荐将common设置为alfa、bravo的peer依赖，这能从根源上避免重复安装的问题：

• 在alfa和bravo的package.json中，把common从dependencies移到peerDependencies：

{
  "name": "alfa",
  "version": "1.0.9",
  // ...其他配置
  "peerDependencies": {
    "common": "^x.y.z" // 填写你需要的common版本范围
  }
}

peer依赖的作用是告诉npm：这个模块需要宿主项目（也就是main-project）提供指定版本的common，不会自行安装common。这样开发时，alfa和bravo会直接使用主项目中link的common，不会在自身node_modules里再装一份，自然就不会出现多版本冲突。

同时，你需要在main-project的dependencies中显式声明common（不管是link还是版本号引用），满足子模块的peer依赖要求。

4. 开发阶段的额外技巧 #

• 如果子模块也需要单独开发测试，你可以在子模块中执行npm link common，同时确保主项目也link了同一个common，配合上面的Webpack alias配置，就能实现全链路的本地开发同步。
• 可以考虑使用npm workspaces（或yarn workspaces）管理多模块项目，它能自动处理模块间的依赖链接，避免手动npm link的繁琐，同时确保所有模块共用同一个node_modules中的依赖。

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