如何在Angular库的npm workspaces中使用allowedNonPeerDependencies？

核心问题根源 #

网上示例能构建成功的原因大多是未遵循Angular库的正式发布规范：要么仅做本地开发演示，未触发完整的ng-packagr生产构建检查；要么使用了旧版ng-packagr，当时还未添加强制peer依赖校验逻辑。ng-packagr的报错是在强制执行Angular库的标准规则——框架核心依赖必须放在peerDependencies，而非dependencies。

正确的依赖拆分规则（适配npm Workspaces） #

结合npm Workspaces特性，Angular库的依赖应按以下规则分类：

• 框架核心依赖（@angular/core、@angular/common等）：必须放在peerDependencies
  • 原因：这类依赖由使用你的库的宿主应用提供，避免重复打包，同时保证版本一致性，符合Angular库的发布标准。
  • npm Workspaces适配：在根目录安装一份公共的框架依赖，所有子项目（库、应用）会自动共享根目录的node_modules，本地开发时不会出现依赖缺失问题。
• 独立工具类依赖（如lodash、date-fns）：放在dependencies
  • 原因：这些是库运行必需的、不会与宿主应用产生版本冲突的依赖，会被打包进库的发布产物中。
• 开发工具依赖（ng-packagr、@angular-devkit/build-angular等）：放在devDependencies
  • 仅用于本地构建、测试，不会出现在发布产物的依赖声明里。

如何简化多库配置？ #

如果手动维护每个库的allowedNonPeerDependencies太繁琐，可以用以下方式优化：

1. 统一根目录依赖：在根package.json中安装所有库需要的公共peer依赖（如@angular/core），并声明版本范围，所有子项目的peerDependencies只需复用相同的版本范围，无需重复安装。
2. 自动同步配置脚本：写一个简单的Node脚本，遍历每个库的package.json，提取dependencies中的依赖名，自动写入对应库的ng-package.json的allowedNonPeerDependencies字段，避免手动复制出错。示例脚本：

const fs = require('fs');
const path = require('path');

// 遍历workspace中的库目录
const libsDir = path.resolve(__dirname, 'projects');
fs.readdirSync(libsDir).forEach(libName => {
  const libPackagePath = path.join(libsDir, libName, 'package.json');
  const libNgPackagePath = path.join(libsDir, libName, 'ng-package.json');
  
  if (fs.existsSync(libPackagePath) && fs.existsSync(libNgPackagePath)) {
    const packageJson = require(libPackagePath);
    const ngPackageJson = require(libNgPackagePath);
    
    // 提取dependencies作为allowedNonPeerDependencies
    ngPackageJson.allowedNonPeerDependencies = Object.keys(packageJson.dependencies || {});
    
    fs.writeFileSync(libNgPackagePath, JSON.stringify(ngPackageJson, null, 2));
    console.log(`Updated ng-package.json for ${libName}`);
  }
});

3. 临时禁用检查（不推荐）：如果你的库仅在内部workspace使用、不对外发布，可以临时用allowedNonPeerDependencies": ["*"]，但长期来看会埋下依赖冲突的隐患。

总结 #

不要被网上的简化示例误导，Angular库的peerDependencies规则是为了保证包的兼容性和避免冗余打包，npm Workspaces只是优化本地依赖管理的工具，两者完全可以共存。按照标准规则拆分依赖，既能满足本地开发的便利性，又能符合包发布的规范。

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