Angular рабочее пространство - Могу ли я разделить зависимости в нескольких пакетах. json?

Question

Рабочая область Angular позволяет мне добавлять несколько проектов в моно-репо, и это здорово. Однако, работая с несколькими командами, я заметил, что это может привести к путанице, если у вас есть только один пакет. 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

Идея состоит в том, чтобы иметь пакет. json для каждого вспомогательного приложения, поскольку оно позволяет командам обновлять свои зависимости независимо. Это возможно?

Answer 1

Я думаю, что ответ «да и нет».
Пока вы хотите остаться с ОДНОЙ заявкой (одна сборка, один артефакт), тогда ответ - нет.

Но, если ваши команды работают над разными, отдельными функциями, возможно, стоит подумать о создании нескольких библиотек (https://angular.io/guide/creating-libraries).

У каждого Lib будет свой пакет. json. Но перед тем, как вы go сделаете этот шаг, я думаю, вам следует проанализировать свою структуру зависимостей (и варианты использования в бизнесе), чтобы убедиться, что код будущей библиотеки не зависит от того, что находится за ее пределами.

Вы МОЖЕТЕ иметь своего рода дерево зависимостей (Основное приложение использует Lib-A и Lib-B, Lib-A и Lib-B использует Lib- C, ...), но вы должны проверить, чтобы не было циклических c зависимостей и "более низкая" библиотека никогда не должна зависеть от "более высокой" библиотеки.

Подход с библиотеками оказывает большое влияние на процесс разработки. Другой процесс сборки, более разделенная / отделенная база кода, это может повлиять на дизайн кода разными способами, ...
Так что это не небольшое изменение. Но это также дает вам много плюсов.
Так что библиотека может получить новые версии, в то время как другие части приложения будут использовать старую, пока эти команды не будут готовы к обновлению. Разделение на библиотеки делает все приложение менее разрушаемым, потому что библиотеки будут общаться друг с другом только через определенные интерфейсы. ...

Так что да, у вас может быть несколько package.jsons. Но это как иметь несколько небольших проектов. Со всеми его достоинствами и недостатками.