Module federation version handling

I have a question regarding version handling of webpack module-federation when developing and addon.

If an addon registers its resources via webpack module-federation all the dependencies are compiled as chunks within the package. For example plone.app.mosaic has dependencies on @patternslib/patternslib and @plone/mockup. So far so good since MF loads modules only once within the whole stack.

plone.app.mosaic versions:

  • @patternslib/patternslib: *
  • @plone/mockup: ^5.0.0-alpha.22

plone.staticresources comes with:

  • @plone/mockup: 5.0.0-alpha.24

and mockup has the following dependency:

  • @patternslib/patternslib: 9.7.0-alpha.0

Questions:

  • Is @patternslib/patternslib needed at all in mosaic if there's already a dependency on @plone/mockup?
  • what's the version * standing for?
  • Is it a problem if mosaic has a mockup version prior to the one in the core or does Plone automatically use the latest available mockup version?
  • Is there a way to define the mockup version like: "use latest from plone" ?

There are several addons coming up with MF support and they nearly all have outdated mockup versions as dependency. It would be great if those addons would pick up latest mockup automatically.

1 Like

Hi,

  1. @patternslib/patternslib is also a direct dependency of plone/mockup. So it is not strictly necessary to be included in package.json.
    Personally Iā€Œ do like to have all dependencies explicitly defined but it can be that the whole package interdependencies can get in our way.

  2. The * version specifier means that any version is good. That's of course not really true, we need some minimum version and mosaic might not compatible with a future version. But with * it's basically: "I don't care yet, take anything." Not sure, if we want that or switch back to ^x.y or >= x.y. Also see: package.json | npm Docs

  3. If multiple versions are found, webpack module federation resolves this to the latest compatible version. If Mosaic depends on @plone/mockup: ^5.0.0 and plone.staticresources ships with @plone/mockup in version 5.1.0, it would choose 5.1.0. If staticresources would ship with 6.0.0 both version would be included due to the package.json version specifiers.

  4. Yes, according to the mentioned package.json documentation we can use tags and thus use latest in our packages where we depend on @plone/mockup. We can also use >= 5.0.0-alpha.24 if we need to depend as a minimum on a specific alpha or beta version version (pre-release versions are not automatically picked except if explicitly requested).

Saying that, I we probably should use latest or >= 5.0.0-alpha.24 < 6 in addon-packages.

There needs to be another update on GitHub - plone/bobtemplates.plone: Python Code Templates for Plone Projects with mr.bob and GitHub - Patternslib/pat-PATTERN_TEMPLATE: Pattern template to bootstrap a new project before the conference.

2 Likes