Release 8.0.0

8.0.0 (2022-05-17)

Features

• Build: Dynamic Module Federation. Add config files and helpers. (7e7a2af)
  With module federation you can share dependencies over multiple bundles without
  loading them multiple times.

The dynamic part here allows the host to not know anything about it's remotes.
This concept can be used for add-ons to a base bundle.
Thanks @manfredsteyer for the help getting this to work!

Use the webpack/webpack.mf.js to extend your own webpack configuration with
dynamic module federation support.
In your main bundle (the "host") use webpack/dynamic_mf.js to configure the
entry point.

For more information see: docs/developer/module-federation.md.
For the general concept see: https://webpack.js.org/concepts/module-federation/

Co-authored-by: Johannes Raggam thetetet@gmail.com
Co-authored-by: Manfred Steyer manfred.steyer@gmx.net

• Build: Register jQuery globally without expose-loader. (dca0842)
  Remove the dependency on expose-loader and register jQuery globally in the
  globals.js module.

Import this module early to have jQuery registered for scripts which depend on
a global jQuery object.

This also fixes an additional request made by the expose-loader for
asynchronously loading jQuery.

• core dom: dom.template engine. (61ca46f)
  Add a simple template engine in core.dom.template
  based on JavaScript template literals.

Maintenance

• Build: Compatibility with Jest 28. (1795087)
  Don't transform preact.

• Build: Compatibility with Jest 28. (69b7934)
  Remove jest-raw-loader dependency and add own loader based on keplersj/jest-raw-loader#239 for compatibility with Jest 28.

• Build: Compatibility with Jest 28. (5679db0)
  Add jest-environment-jsdom as of jest 28 that isn't shipped anymore by default.

• Build: Upgrade dependencies. (3260038)

• Build: Upgrade fullcalender. (0b08573)

• Build: Upgrade luxon to version 2. (5d12b9e)

• Bundle: Upgrade jest to version 28. (4ac079f)

Breaking Changes

• core registry: Use a global pattern registry. (737f3ed)
  Previously it was possible to use multiple pattern registries when multiple
  instances of the registry were used, e.g. in different bundles.

With this change we do use only one pattern registry storage which is
shared across instances of core.registry in multiple bundles.

This is a transparent change - the Patternslib registry API has not
changed at all. Just keep using registry.scan,
registry.register, etc.

But if necessary, there is a PATTERN_REGISTRY export in core.registry
which points to window.__patternslib_registry, a singleton in the global
namespace which is shared across instances of the registry.