Multiple Versions of Angular in a page

[Paitum]

My organization runs a complex AngularJS-Angular-Hybrid portal that other teams contribute to. Having a large portal managed by various teams is unsustainable since everyone must move together as the platform evolves.

I have an idea where we breakup the monolithic portal into many portals which each share an "Application Shell". That way the user gets a single cohesive experience but is actually accessing different applications.

I would like to write this Application Shell in Angular, but since it would be responsible for loading other Angular applications, it is unclear whether or not that would even work. Technically, the "Application Shell" should be agnostic to the content it loads, meaning that it should not interfere or conflict with the content implementation.

Does Angular support running multiple versions in a page? e.g. Angular 6 and Angular 7, each controlling different DOM-trees.

If not, is there a way to work around limitations? For example, if the reason it doesn't support multiple version is due to zone.js conflicting-- then can we simply work with Angular and manage our own change detection?

Do Angular Elements support running along side another Angular application?

We are exploring all of these questions ourselves, but I figured asking the community could be helpful. Many thanks.

[Sander Elias]

Hi Paitum,

Yes, you can load different angular versions in 1 page, but you need to take care of zonejs. There can be only 1 zonejs.

Going without zonejs is also a possibility, but you need to be at least on 7, to make that workable. 

Yes, you can run angular elements in another angular app, but you have no access to its services.

I really would recommend going to a monorepo, and sync on a single angular version. Version 8 is out, and in version 9 ivy will be the default renderer. 

Have a look at a tool like NX, from nrwl. That will enable you to manage a monorepo, while it makes it a lot easier to keep things in sync.

Regards

Sander

[Paitum]

Sander,

Thanks for the reply.

First, I want to re-explain that we cannot sync on a single angular version. Our website is basically a single runtime platform that lazy-loads "plugin code". The plugin code must therefore be on the same version of Angular-- which creates the problem of having a monolithic application.

I have previously looked at NX, but have serious concerns about how to manage a monorepo beyond simply the build infrastructure. For example, how can our enterprise wide "git" infrastructure handle a monorepo. It is my understanding that git doesn't have good monorepo support.

Finally, today I tried to test this all out, but am definitely running into problems. I used the Angular CLI to create two projects and built them. I then attempted to take those /dist/** files and put them together into a single webpage. Needless to say I'm still working on it but haven't had the result I expected. I wonder if these Angular CLI support files are not compatible with each other (runtime.js, vendor.js, etc). (Yes, I removed zone.js from both).

I'll reply back if I make any progress.

[Paitum]

In my mind, the platformBrowserDynamic().bootstrap function would be unique and fully encapsulated within each application. My fear is that its implementation uses window and therefore could conflict with itself.

I also wonder if generated files share some webpack declarations that also conflict, since both project are built from the same Angular CLI, and therefore both register a "main" for example.

[Sander Elias]

Hi Paitum,

Depending on how your projects/teams are organized, different demands are coming into play.

A monorepo is a solution, but it doesn't work for everyone. reading this back, I think your situation does not really fit the mono-repo workflow. (Still, this would solve quite some problems. Yarn workspaces and NX are tools that make it easier, but GitHub might not provide the granularity you need in access rights and so)

If I was in your place, I would hand each team a set "shell" in where they can provide their lazy-loadable modules or Angular-elements. (the later would have my preference, and opens up the door to a more flexible integration path)

The shell will provide the company width things (usually auth, and access to certain DB's that most (if not all) teams need.

This requires a sing;e angular version but updating from 6 or 7  to 8 should not be a big deal.

For deployment, you use a souped-up shell, that is capable to instantiate every team's module. (if those are elements, its really loading the script, and add the element to the page.) 

Angular Elements are an excellent solution for portals. But make sure you set the requirements for the outlets/widgets/pages/whateverYouCallt are clear. (simple sample, for a widget you might say x and y size is max 300px, and should be an increment of 50, so it fits the'grid') 

The build story for angular elements will improve a lot, but it is already usable for the situation you are in now.