版本冲突
一、认识
在 PNPM 的 Monorepo 项目中，当子项目中的依赖版本不一致时，PNPM 会将不同版本的包分别安装在每个项目中。由于 node_modules 中使用了符号链接，不同版本的包可能在子项目中被引入，从而导致依赖解析和模块加载的问题。
例如：假设 app-a 和 app-b 使用不同版本的 lodash，由于 PNPM 使用了符号链接，这些版本的 lodash 会分别被安装在 app-a 和 app-b 的 node_modules 中。虽然这些版本的 lodash 通过符号链接指向相同的全局存储位置，但在 Webpack 处理这些符号链接时，可能会出现问题。
Webpack 使用相应的插件进行代码压缩和混淆。假设 app-a 和 app-b 中的 lodash 被混淆为标识符 a，由于 lodash 版本不同，这个标识符 a 可能指向不同的实现。即使它们在代码中使用相同的标识符，实际引用的 lodash 版本却不同，导致功能不一致或运行时错误。
解决方案如下:
-
解决模块版本冲突，确保版本一致:
-
overrides:overrides是在pnpm中用于解决版本冲突和确保依赖一致性的一种功能。你可以在根目录的package.json中使用overrides字段来指定特定依赖的版本。 -
.pnpmfile.cjs是pnpm提供的自定义配置文件，可以用来实现更复杂的依赖处理逻辑，如动态覆盖版本、调整依赖结构等。 -
基于
resolve.symlinks避免符号链接路径的问题: 在Webpack配置中，将resolve.symlinks设置为false可以避免因符号链接路径导致的问题。这将确保Webpack不会因为符号链接指向的不同版本或路径而引发依赖解析和功能不一致的问题。
二、overrides
overrides: overrides 是在 pnpm 中用于解决版本冲突和确保依赖一致性的一种功能。你可以在根目录的 package.json 中使用 overrides 字段来指定特定依赖的版本。
2.1 语法
在根目录的 package.json 中添加 overrides 字段：
{
"overrides": {
"ukit-lang": "1.2.3"
}
}
2.2 总结
通过 overrides 可以非常简单地指定某个依赖的版本，确保所有工作区都使用这个版本。只需在一个地方（根目录的 package.json）配置，易于查看和维护。在 pnpm install 过程中自动应用，无需额外的脚本或配置文件。 但是， overrides 只支持指定版本号，对于更复杂的依赖调整需求（如条件逻辑或动态覆盖），overrides 可能无法满足。同时，不能根据包的不同版本或情况应用不同的版本覆盖策略。
所以，overrides 适用于简单的版本冲突解决和版本一致性保证，特别是当你只需要为所有工作区统一某个依赖的版本时。
三、.pnpmfile.cjs
.pnpmfile.cjs 是 pnpm 提供的自定义配置文件，可以用来实现更复杂的依赖处理逻辑，如动态覆盖版本、调整依赖结构等。
2.1 语法
const packageJson = require('./package.json');
// 列出需要覆盖版本的依赖包名称
const packagesToOverride = ['lodash'，'ukit-lang'];
/**
* 构建需要覆盖版本的依赖映射
* @returns {Object} 包含需要覆盖版本的依赖映射
*/
function createDependencyOverrides() {
const overrides = {};
// 从 dependencies 中添加需要覆盖的包
for (const [pkgName, pkgVersion] of Object.entries(packageJson.dependencies)) {
if (packagesToOverride.includes(pkgName)) {
overrides[pkgName] = pkgVersion;
}
}
// 从 devDependencies 中添加需要覆盖的包
for (const [pkgName, pkgVersion] of Object.entries(packageJson.devDependencies)) {
if (packagesToOverride.includes(pkgName)) {
overrides[pkgName] = pkgVersion;
}
}
return overrides;
}
const dependencyOverrides = createDependencyOverrides();
/**
* 根据配置覆盖包的依赖版本
* @param {Object} pkg - 当前处理的包
* @param {Object} context - 钩子上下文
* @returns {Object} 修改后的包
*/
function applyVersionOverrides(pkg, context) {
// 遍历 dependencies 并覆盖版本
Object.entries(pkg.dependencies).forEach(([depName, depVersion]) => {
if (dependencyOverrides[depName]) {
pkg.dependencies[depName] = dependencyOverrides[depName];
context.log(`Overridden ${depName} to version ${dependencyOverrides[depName]}`);
}
});
// 遍历 devDependencies 并覆盖版本
Object.entries(pkg.devDependencies).forEach(([depName, depVersion]) => {
if (dependencyOverrides[depName]) {
pkg.devDependencies[depName] = dependencyOverrides[depName];
context.log(`Overridden ${depName} to version ${dependencyOverrides[depName]}`);
}
});
return pkg;
}
module.exports = {
hooks: {
readPackage: applyVersionOverrides,
},
};
2.2 总结
.pnpmfile.cjs 允许在处理依赖时应用复杂的逻辑，如动态调整、条件覆盖等。可以根据包名、版本、上下文等条件实现不同的版本覆盖策略。同时提供了更细粒度的控制，可以在日志中记录覆盖信息，帮助调试问题。
因此，.pnpmfile.cjs 适用于需要复杂逻辑、条件覆盖或动态版本处理的情况。当你的项目需要根据不同的工作区或其他条件应用不同的依赖版本时，.pnpmfile.cjs 提供了更大的灵活性。
四、resolve.symlinks
在 Webpack 配置中，将 resolve.symlinks 设置为 false 可以避免因符号链接路径导致的问题。这将确保 Webpack 不会因为符号链接指向的不同版本或路径而引发依赖解析和功能不一致的问题。
在 Monorepo 中，使用符号链接可以在不同的子项目中共享依赖。将 resolve.symlinks 设置为 false 时，Webpack 不会解析符号链接的实际目标路径，而是将其视为依赖项的实际位置。这样做可以避免因为符号链接指向不同的版本或位置而引发的冲突或解析问题。
如果不同的模块或子项目使用不同版本的相同依赖，并且这些版本通过符号链接共享，设置 resolve.symlinks 为 false 可以帮助 Webpack 确保始终使用实际的模块版本而不是链接的路径，从而解决版本不一致的问题。
4.1 语法
// webpack.config.js
module.exports = {
resolve: {
symlinks: false
}
};
4.2 总结
resolve.symlinks: false 配置用于确保 Webpack 处理符号链接时不会将其解析为目标路径，而是将其视为实际依赖。这可以解决由于符号链接引起的模块版本冲突和路径解析问题，特别是在 Monorepo 环境中。通过确保 Webpack 只关注实际的模块路径，可以避免由于符号链接引起的复杂性和潜在的错误。