是否应执行ng eject导出Webpack配置？Angular4项目该操作优劣分析

先直接给你结论：除非你有绝对必要的自定义Webpack需求，否则不建议执行ng eject。针对你遇到的PrimeNG警告问题，完全有不需要eject的解决方案，我帮你拆解清楚：

是否应该执行ng eject？ #

简单说：能不用就不用。ng eject是Angular CLI早期版本里把封装好的Webpack配置“暴露”出来的命令，但它是不可逆操作——一旦执行，你的项目就和Angular CLI的默认构建流程解绑了，后续没法再轻松使用ng build、ng serve这些CLI原生命令（除非手动恢复配置，非常麻烦）。

ng eject的优缺点 #

优点 #

• 完全掌控Webpack配置：可以自定义loader、插件、打包规则，解决CLI默认配置无法覆盖的特殊需求（比如特定资源打包、自定义环境变量处理）。
• 排查构建问题更直接：如果遇到CLI层面难以定位的构建错误，直接修改Webpack配置会更高效。

缺点 #

• 不可逆性：执行后无法再轻松回到CLI的默认工作流，后续Angular CLI的更新（比如性能优化、新特性）你也没法直接受益，得自己手动同步到Webpack配置里。
• 维护成本飙升：你需要自己维护整个Webpack配置，包括处理依赖版本兼容、配置优化，对于不熟悉Webpack的开发者来说，这会变成很大的负担。
• 项目复杂度提升：原本CLI帮你隐藏的构建细节全部暴露，团队协作时需要所有人都了解项目的Webpack配置，增加了协作成本。

针对你的PrimeNG警告场景的替代方案 #

你遇到的Cannot find source file警告，本质是PrimeNG的npm包中附带的source map文件指向了其源码目录（而这些源码在npm包中并不存在），当你的Shared项目间接引用PrimeNG组件时，CLI的构建工具在处理source map时找不到对应的源文件，从而抛出警告。完全不需要eject就能解决：

方案1：关闭第三方依赖的source map生成 #

在Angular 4的angular-cli.json配置文件中，修改defaults下的sourceMap配置，关闭vendor（第三方依赖）的source map：

"defaults": {
  "sourceMap": {
    "scripts": true,
    "styles": true,
    "vendor": false
  }
}

这样构建时就不会处理第三方依赖的source map，自然就不会出现找不到源文件的警告。

方案2：调整Shared项目的依赖配置 #

把PrimeNG列为Shared项目的peerDependencies而非dependencies，在Shared项目的package.json中：

"peerDependencies": {
  "primeng": "^4.x.x",
  "primeicons": "^1.x.x"
}

这样引用Shared项目的两个主项目会各自安装PrimeNG，避免重复打包，同时也能让CLI正确识别PrimeNG的路径，减少路径相关的警告。

方案3：确保Shared项目中正确导入PrimeNG组件 #

在Shared项目中，确保你是从PrimeNG的正式包路径导入组件，而不是从相对路径引用：

// 正确的写法
import { OrderListModule } from 'primeng/orderlist';

// 错误的写法（不要这样）
import { OrderListModule } from '../node_modules/primeng/components/orderlist/orderlist';

规范的导入方式能让CLI正确解析依赖路径，避免出现源文件查找错误。

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