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 😁