feat(nf): implement singleton & requiredVersion compatibility checks

[gpaucot]

Switching to native federation I noticed the strategy did not take into account the singleton and requiredVersion yet.
Here is an implementation with JSDoc & UT.

I also tested it locally with 4 angular workspaces, at the image of what we use in my company:

• v18.2.4 workspace with a shell and a mfe using a core library (sharedMapping).
• v17 workspace intended to represent another team's work with a MFE using the core from the shell. This allows me to verify that an older major works (required version >=17.0.0)
• v18.2.3 workspace intended to represent another team's work with a MFE using the core from the shell. This allows me to verify that a v18 but slightly behind works (required version ^18.0.0) and load it during initFederation or later on routing with loadRemoteModule.

@manfredsteyer I hope this does not diverge from the path you are willing to take for the future 🙂 If you find a little time to make a feedback I would be very grateful

Cheers,
Gaëtan

[okamiconcept]

I'm very surprised that this core base feature (semantic versioning between shell and remote) is not yet in the Native Federation package since it's the main feature of Module Federation...

For the moment the library is just usable if you have the same packages versions in the host and the remote, especially for the Angular version, if the remote have the version 18.1.0 and the shell 18.1.1 there will be 2 different angular framework loaded, each one with it's own injector, so they can't communicate with each other.

@manfredsteyer do you use it already in production?

FYI i've created a patch in the meantime (with an other approach, simpler: #399 (comment))

[rainerhahnekamp]

@gpaucot @okamiconcept. The problem is that Angular - once compiled - doesn't provide compatibility between patch levels. So if we would allow to merge multiple Angular versions together, you might run into some serious issues.

It is the same with module federation btw.

The question is if we want to still allow it (with a big warning message "at your own risk").

You can also checkout this video stream where Minko Gechev explains the problem: https://youtu.be/oQbLkcws_pQ?si=IFntfQ0k0HvSHx26&t=2271 (Time Position: 37:51)

The alternative would be to combine NF/MF with Web Components, aka. Frankenstein solution.

[okamiconcept]

@rainerhahnekamp Yes you are totally right, there is a chance of incompatibility, but there is still a possibility of specifying the compatibility of the versions between them by using specific semantic versioning in the package.json or by specifying directly in the federation.config.js

There is always a upgrading strategy between master / remotes to be sure there is no incompatibility, with some regression tests, to ensure there is a compatibility between patch / minor / major versions a least :)

The problem here is that we cannot mimic the basic Module Federation implementation for now, so there is no chance of letting us decide if we take the risk of accepting compatibility between 2 versions of Angular (or any other library).

[Nxtivision]

Any news of this? Because we have the same problem inside our company 😁

[rribeiro93k]

@rainerhahnekamp based on @okamiconcept last comment, It will be some update about this case? I also understand
about Angular incompatibility for some different versions, but It shouldn't configurable? for my understanding in native-federation the params requiredVersion and singleton isn't used in fact. This could be a problem for intern libraries, because I need to keep the same version for shell and all remotes to not create multiple instances for singleton services for example

[rainerhahnekamp]

@rribeiro93k, the only thing that you can configure is that you are getting an error on version mismatch. as soon as the angular version of a remote doesn't match the one of the host, you face that risk. you have to remember that from Angular's perspective you give it a lazy loaded module and Angular expects the compiled one to be compliant with that one of the host.

it is not just about sharing.