Angular workspace - Can I seperate dependencies in multiple package.json?

user_2315774 0
Viewed 1434

The Angular Workspace allows me to use add several projects into a mono-repo, which is great. However, working with several teams, I have noticed that it can get really messy if you only have one package.json and have each team edit that with the app they are writing.

Is it possible to have a struture like this?

|── 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

The idea is to have a package.json for each sub application, as it allows for teams to update their dependencies independently. Is that possible?

angular7 angular6 angular9 angular8 angular
1 Answers

I think the answer is "yes and no".
As long as you want to stay with ONE application (one build, one artefact), then the answer is no.

But, if your teams are working on different, seperated, features, it may be worth to think about creating multiple libraries (https://angular.io/guide/creating-libraries).

Each Lib will have its own package.json. But before you go this step, i think you should analyze your dependency structure (and the business use cases), to make sure that the code of a future library is not depending on things outside of it.

You COULD have a kind of dependency tree ( Main app uses Lib-A and Lib-B, Lib-A and Lib-B uses Lib-C,...) but you should check to have no cyclic dependencys, and a "lower" lib should never be dependent on a "higher" lib.

The approach with libs has major impact on the developing process. A different build process, a more divided / seperated code base, it may effect the code design in many ways, ...
So its not a small change. But it also gives you a lot of Pros.
So could a lib get new versions, while other parts of the application will still use the old one until those teams are ready for an upgrade. The seperation into libs make the whole application less breakable, because the libs will only talk to each other over defined interfaces. ...

So yes, you could have multiple package.jsons. But its like having multiple small projects. With all its advantages and disadvantages.

user_79987810
Related