Angular Workspace允许我使用将多个项目添加到mono-repo中，这很棒。但是，与几个团队一起工作时，我注意到，如果您只有一个package.json，并且每个团队都使用他们编写的应用程序对其进行编辑，则可能会变得非常混乱。
是否可以具有这样的结构？
|── angular.json
├── browserslist
├── e2e
├── karma.conf.js
├── node_modules
├── package.json <--- I should only be responsible for everything in /src
├── package-lock.json
├── projects
│ └── my-sub-application
│ ├── browserslist
│ ├── karma.conf.js
│ ├── package.json <--- Is this possible? So that "my-sub-application" only pulls its dependencies from this package.json?
│ ├── src
│ │ ├── app
│ │ ├── assets
│ │ ├── environments
│ │ ├── favicon.ico
│ │ ├── index.html
│ │ ├── main.ts
│ │ ├── polyfills.ts
│ │ ├── styles.scss
│ │ └── test.ts
│ ├── tsconfig.app.json
│ ├── tsconfig.spec.json
│ └── tslint.json
├── README.md
├── src
│ ├── app
│ ├── assets
│ ├── environments
│ ├── favicon.ico
│ ├── index.html
│ ├── main.ts
│ ├── polyfills.ts
│ ├── styles.scss
│ └── test.ts
├── tsconfig.app.json
├── tsconfig.json
├── tsconfig.spec.json
└── tslint.json
想法是每个子应用程序都有一个package.json，因为它允许团队独立地更新其依赖关系。那可能吗？
我认为答案是“是和不是”。只要您希望使用一个应用程序（一个版本，一个工件），答案是否定的。
但是，如果您的团队正在开发不同的，分离的功能，则可能值得考虑创建多个库（https://angular.io/guide/creating-libraries）。
每个Lib都有自己的package.json。但是在执行此步骤之前，我认为您应该分析您的依赖关系结构（和业务用例），以确保将来的库的代码不依赖于其外部的内容。
您可能有一种依赖关系树（主应用程序使用Lib-A和Lib-B，Lib-A和Lib-B使用Lib-C，...），但您应检查是否没有循环依赖关系，并且“ lower” lib永远不要依赖于“ higher” lib。
使用libs的方法对开发过程具有重大影响。一个不同的构建过程，一个更加分开的/分离的代码库，它可能以多种方式影响代码设计，...因此，这是一个不小的变化。但这也给您带来很多优点。一个lib可能会获得新版本，而应用程序的其他部分仍将使用旧版本，直到这些团队准备升级为止。分离为库使整个应用程序更不会损坏，因为库仅通过定义的接口相互通信。 ...
所以，可以有多个package.jsons。但它就像有多个小型项目。具有所有优点和缺点。