Nx: Splitting nx.json and angular.json per project

[eliasdarruda]

Hey!

It would be very cool if we could have a tool to split configuration files like angular.json or nx.json per app/lib
Currently we are working in the same repo with a lot of different projects and a lot of people, we always end up having to solve conflicts on these files.

Angular CLI does not support splitting angular.json by default, so we could put a angular-project.ts inside each lib or app and then run a script to concatenate every entry into angular.json

The same idea would work for nx.json, or maybe on nx.json just a flag to search in the directories for a nx.json file or something.

Is there anyone with a similar solution to share?

[dogmatico]

Solving this, even with JSON pointers to external files, will be a great quality of life improvement. Conflicts arising in those files when multiple branches create libraries and projects require, unless I'm doing it wrong and there is a better way, meticulous work to solve and a bit of understanding of the structure of angular/nx.json.

[vsavkin]

I'm with you folks! We work with a lot of clients with 10k angular/workspace json files. So definitely something we are thinking about.

[eliasdarruda]

I made a package to solve this problem, it comes with the cost of having to run a command before every serve and build action to merge the files.
However I don't see any way out of this behaviour for angular.json file.

This plugin solves the conflict and complexity problem for "nx.json", "angular.json" and "tsconfig.json" files.

It would be nice if we could see in the future a flag to at least do it automatically on nx.json file

The package:
https://github.com/eliasdarruda/nx-config-splitter

[jsaguet]

How about alphabetically ordering projects in nx.json, angular.json, tsconfig.json to reduce conflicts ?
Like suggested in #2607, it would help to automatically resolve conflicts if modified lines are not the same.
Maybe it is not adapted to very large projects but it could help for smaller ones

[BenjaminDobler]

I wrote an extension for visual studio code to help me deal with large angular.json files.
The extension allows you to right click on a project on visual studio code and only open this part of the angular.json in a "virtual" editor. You can edit the partial and save your changes back to the angular.json.
It is basically like each project has it's own angular.json but it's all virtually.
Here is the link: https://marketplace.visualstudio.com/items?itemName=richapps.ng-config
If there is interest this could maybe also be integrated into nx console!?

[kylecordes]

We have a project with a 20,000+ line angular.json file; we gave up maintaining this by hand or with schematics, and instead regenerate it frequently based on clues our ad hoc generator gets from the contents of the projects.

So… +1.

[americoneto1]

@vsavkin is there any plan on NX roadmap to solve this issue?

@eliasdarruda schematics changes the content of these files (angular.json, nx.json, etc). I would like to know if your solution also changes the content of base files.

[eliasdarruda]

@vsavkin is there any plan on NX roadmap to solve this issue?

@eliasdarruda schematics changes the content of these files (angular.json, nx.json, etc). I would like to know if your solution also changes the content of base files.

@americoneto1 Base files will stay frozen from the point you copied your original angular.json file to a .base file, it proved to be a good solution for our team, after implementing it we never had to solve conflicts of these files again

[bubblegumsoldier]

We have a project with a 20,000+ line angular.json file; we gave up maintaining this by hand or with schematics, and instead regenerate it frequently based on clues our ad hoc generator gets from the contents of the projects.

So… +1.

Which ad hoc generator do you use? Is it a proprietary one or open source?

@vsavkin is there any plan on NX roadmap to solve this issue?
@eliasdarruda schematics changes the content of these files (angular.json, nx.json, etc). I would like to know if your solution also changes the content of base files.

@americoneto1 Base files will stay frozen from the point you copied your original angular.json file to a .base file, it proved to be a good solution for our team, after implementing it we never had to solve conflicts of these files again

I really like your project but I am a bit scared about building a companies platform on a one-person repository dependency at the core of project structure. Are there any plans on how you are going to maintain the project considering angular updates, etc? Or do you know about any other alternatives?

[bubblegumsoldier]

I'm with you folks! We work with a lot of clients with 10k angular/workspace json files. So definitely something we are thinking about.

Are there specific plans, tickets or similar currently open?

[jimbarrett33]

Very interested in a built-in NX solution for this. In general, different teams work on different apps in the monorepo with different build configurations but use common libraries under /libs. So even if there was just a single "libs.angular.json" with all the libs and an "app-.angular.json" for each app that would help a lot. The lib entries in angular.json are fairly standard format and changes would be much easier to merge without all the apps embedded in the same angular.json.

[labeled]

+1

[areknow]

Agreed that a built in NX solution would be great! We are scaling fast and are feeling the conflict pains in our angular.json file and other root files. Thanks!

[josecolella]

Definitely agree that as best practices dictate to generate libs and modularize features into libs, this problem will only get worse.

[kylecordes]

@bubblegumsoldier

Which ad hoc generator do you use? Is it a proprietary one or open source?

Just a couple hundred lines of TypeScript we wrote, full of assumptions of the specific shape of the projects in our workspace. So proprietary... but not useful to anyone's else workspace anyway.

[cfrim]

What is the progress on this issue?

[PetarKirov]

We have a project with a 20,000+ line angular.json

This must be cruel joke... does anyone consider this even remotely workable!? My personal tolerance for manually maintained json files is 300 LoC. I can't believe that a project which claims to offer workflow benefits for medium to large projects hasn't addressed this since day 1!