WIP: ESM server support (runs simple examples but not complete - looking for guidance/is this something you would be willing to merge once complete)

[EliLichtblau]

Description

Early stage wip support for esm server - this runs but it currently breaks cjs - so far from mergable. There is definitely an amount of complexity (and just overhead/duplication) added here to be able to support esm servers. So I want to make sure this something you would be ok being merged when complete

Here is a very small example repo using this PR shell and 1 remote (server and client)

Related Issue

https://github.com/module-federation/universe/issues/1918

Types of changes

• [ ] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] (currently breaking) New feature (non-breaking change which adds functionality)

Checklist

• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.
• [ ] I have updated the documentation.

[ScriptedAlchemy]

@EliLichtblau im trying to move the node implementation to leverage as much of the federation runtime and sdk.

I suggest you implement esm support stuff on the sdk or runtime areas.

see here: https://github.com/module-federation/universe/pull/1978/files#diff-4b57cbf3b32c6d0876af72c8172701ba1f473ff218884b41d5444dfe6926cdd9

I replace most the code with federation.runtime.loadScriptNode

[ScriptedAlchemy]

Doing it like this via SDK / runtime - we can slide ImportMaps support into the library and provide tier 1 federation capabilities to anyone, regardless of bundler tech.

I greatly appreciate the effort here. Do you know how this will respond to "hot reload," like if the remote changes and I need to "clear require cache" to fetch a new container? Will vm not get stuck and re-evaluate the same module from string? I avoided ESM as it has issues with busting the require cache, but I think if it's in VM, we may not have this issue. However, I am not sure about memory leaks

[EliLichtblau]

To be completely honest - I do not know - when I do hmr stuff locally (federated or not) I always disable ssr because it kinda gets in the way. I'm pretty sure there are ways of unsticking it but the memory leak I'm less confident of - I will spend more time exploring good ways of doing this! Really cursory reading around - its a little jank - but it seem possible - this thread even recommending worker threads.

Appreciate all the advice!

[ScriptedAlchemy]

Yeah but worker threads is not a viable solution IMO. It works but in reality i have only see a handful of users do this. Most are on aws lambda.

We can use vm.Module() and evaluate modules in the VM, that will let us dispose of the VM / reload it. Still itll leak memory but thats probably going to be a reality for a long time.

[github-actions[bot]]

Stale pull request message