angular-cli
angular-cli copied to clipboard
Split `angular.json` into multiple files
🚀 Feature request
- [x] new
- [x] build
- [x] serve
- [x] test
- [x] e2e
- [x] generate
- [ ] add
- [ ] update
- [x] lint
- [ ] extract-i18n
- [x] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
Description
I have a monorepository and I want to split my angular.json into separate files.
So that I can have something like this:
{
"version": 2,
"projects": {
"module-auth": "packages/auth",
"module-core": "packages/core",
"module-button": "packages/button"
}
}
After working with NX I noticed that with Lerna and the usual setup my angular.json file has 119 lines of code even though I basically have an empty repository. I believe that having a single angular.json file is a very bad idea, especially for bigger monorepositories or UI libraries.
Describe the solution you'd like
Make the JSON configuration 1:1 with what NX does or implement similar functionality.
Splitting angular.json into multiple projects level configuration is something that we definitly want to explore in the future.
However, it is very unlikely that it will 1:1 with the NX solution.
This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list.
You can find more details about the feature request process in our documentation.
I think that such functionality will lead to a win-win situation for both Angular and Nx.
- ng cli users will get more intuitive and fast code locating
- nx cli team will get an opportunity to adopt the new native approach of splitting
angular.json(and remove some hacks related to v2 schema)
cc: @vsavkin
@Den-dp I will share this issue with more people maybe it will get at least into the consideration list. I have no idea why would anyone dislike this and I would like to hear counterarguments. 😅
Personally, if I had to work on a monorepo with Angular and without nx I would write a custom script that would build the angular.json file the way I described.
It is essential to address this in Angular now, especially with the advent of native federation, which simplifies the process of working on microfrontends within Angular workspaces. Managing a large angular.json file in this context is neither ideal nor efficient and can become quite cumbersome.
Anything new regarding this?