Compiling different parts of an Angular app in separate passes? about angular

[JoostK]

Angular supports an intermediary compilation target that can be enabled by setting "compilationMode": "partial" in "angularCompilerOptions" in the relevant tsconfig file. This causes the compiler to output partial declarations in places where it would otherwise emit code instructions. This mode has been designed for library compilations, where a library needs to be compatible with multiple versions of Angular runtimes, possibly newer than the compiler version that was used when building the library.

Partial declarations are therefore not bound to one specific Angular version (they do require a minimum Angular version, which is also specified in the declaration). Such partial declarations then need to be transformed in a build-transform at the moment an application is built, which we refer to as linking. This is implemented using a Babel plugin (some more in https://github.com/angular/angular-cli/blob/main/packages/ngtools/webpack/README.md#ivy-linker) that transforms single files at a time, as partial declarations are self-contained. The output is the fully-compiled code instructions that are specific to the runtime that corresponds with the linker version.

---

Another consideration is that we'd like to support multiple versions of Angular in the same application because the core Mesop framework may want to upgrade Angular but the ecosystem of custom Mesop components could take more time to upgrade to the latest Angular version. IIUC, this is quite hairy because Angular has a global runtime which monkeypatches globals (e.g. zone.js) and having multiple versions of the runtime could cause issues. Is that right?

I wouldn't recommend running different runtime versions side-to-side in a single JS realm. I haver never attempted it to give more meaningful insight into what problems this would bring along.

[alxhub]

👋 hey Will!

The pattern you're describing is essentially "i want my application to load and link code that wasn't compiled with it", which is not a unique problem to Angular. There are a few popular solutions in the JavaScript ecosystem, such as Module Federation. While the Angular CLI doesn't have first-party support for this mode of operation, our community has built third-party integrations.

There are different architectures possible here, with different tradeoffs, but the most common / sensible one would be that Mesos is the host application, and selects the Angular runtime version. Plugins (custom components) are built separately, and use the runtime from the host application. This is technically possible, although tricky to implement and has a few caveats (mostly related to NgModules not working properly).

Things get easier if it's possible to compile the host application and all the custom components together, of course.

Another consideration is that we'd like to support multiple versions of Angular in the same application because the core Mesop framework may want to upgrade Angular but the ecosystem of custom Mesop components could take more time to upgrade to the latest Angular version. IIUC, this is quite hairy because Angular has a global runtime which monkeypatches globals (e.g. zone.js) and having multiple versions of the runtime could cause issues. Is that right?

I don't think this is really a problem. In Angular, an application using version X can reliably use libraries built with a minimum version of X - 2 - this is the backwards compatibility guarantee we provide. So if you think of the custom components as libraries, it's fine for them to fall behind the main application in their Angular version.

The opposite isn't true - you can't write such a component using version X + 1 and expect it to work in an application running Angular X. It's easy to see why this is the case: such a component could make use of features of Angular X+1 that wouldn't be supported by the runtime used in the application.

[wwwillchen]

Thanks for the responses - appreciate the detailed explanation. I'll revisit the option of compiling everything together in one pass as that seems like the recommended approach.