Skip to main content

Commons

Commons is a library that is part of the FrontHub core and its main function is to provide other common libraries (hence the name) for all micro frontends (MFEs) in production and staging environments. It must always be present in the dependencies of each micro frontend.

The libraries provided by Commons are the following:

  • axios
  • clsx
  • i18next
  • numeral
  • react
  • react-dom
  • react-hook-form
  • react-i18next
  • react-is
  • react-router-dom
  • redux
  • regenerator-runtime
  • styled-components
  • uuid

Libraries from this list that are used by the MFE must be properly configured in the dependencies section of their package.json file.

Next, we will detail the versions of these libraries provided by Commons and explain how its versioning works. Before that, it's important to understand the problem this library solves.

What is it for?​

Simply put, Commons aims to prevent the end user from having to download the same dependencies multiple times across different micro frontends.

Let's break this down. See the image below:

A coffee ecommerce detail page showing the fronthub coffee

In the figure, we identify three micro frontends loading simultaneously, marked by the borders (red, green, and blue). All of these micro frontends require essential dependencies to function correctly, such as React, React DOM, and styled-components. If each of these micro frontends downloads these dependencies separately, the user will have to load the same resources three times.

This problem becomes even worse as we add new micro frontends, each requiring the same dependencies.

In short, the end user would be penalized by the micro frontend architecture. This is where Commons comes into play, providing a centralized solution that eliminates this redundancy. Next, we'll see how this works in practice.

How does it work?​

In the configuration file, it is defined which package will be responsible for providing the common libraries. By default, this package is @resultadosdigitais/front-hub-commons, and so far, there is no other package that performs the same function.

With this configuration, during the build process, the specified package is located among the micro frontend dependencies. If the package is not present, an error will be generated, and the build process will be halted.

Validation of commons dependencies​

In both the development and production build processes, there is a validation process that is important to highlight. This involves validating the versions, following the SemVer standard, of all the libraries provided by Commons that are also declared in the package.json. The validation scenarios include:

1) Common dependency registered as devDependencies​

If a common dependency (any from the initial list) is registered in the devDependencies section of the MFE's package.json, an error will be thrown, and the build process will be halted. All common dependencies used in the MFE must be in the dependencies section of the package.json.

Build error for production because detected common dep in devDependencies
Build error for production
Build error for development because detected common dep in devDependencies
Build error for development

2) Common dependency with higher MINOR/PATCH version​

If a common dependency (any from the initial list) is registered with a MINOR or PATCH version higher than the version provided by Commons, an error will be thrown, and the build process will be halted.

For example, if the react dependency is registered at version 18.3.2, but Commons provides version 18.3.1, the build will be interrupted.

Build error for production because detected common dependency with higher MINOR/PATCH version
Build error for production
Build error for development because detected common dependency with higher MINOR/PATCH version
Build error for development

3) Common dependency with lower MINOR/PATCH Version​

If a common dependency (any from the initial list) is registered with a MINOR or PATCH version lower than the version provided by Commons, a warning will be issued, and the build process will not be halted.

For example, if the react dependency is registered at version 18.2.1, but Commons provides version 18.3.1, the warning will be issued, but the build will not be interrupted.

Warning in production build because detected common dependency with lower MINOR/PATCH version
Warning in production build
Warning in development build because detected common dependency with lower MINOR/PATCH version
Warning in development build

4) Common dependency with different MAJOR Version​

If a common dependency (any from the initial list) is registered with a different MAJOR version (regardless of whether it is higher or lower) than the version provided by Commons, an error will be generated, and the build process will be halted.

For example, if the react dependency is registered at version 17.0.1, but Commons provides version 18.3.1, the build will be interrupted.

Build error for production because detected common dependency with MAJOR difference
Build error for production
Build error for development because detected common dependency with MAJOR difference
Build error for development

Once the validation is done, there is a significant difference between the development build (yarn start) and the production build (yarn build). Let's separate the explanations for each of them.

Development build​

When FrontHub identifies that a development build is being generated, it performs only the validation mentioned earlier, without modifying anything after compilation.

Production/staging build​

When FrontHub identifies that a production build is being generated, all common dependencies registered in the package.json are removed from the final bundle and configured as externals. For more information, see the Webpack documentation. This configuration indicates that all these dependencies will be served outside the micro frontend bundle, thereby reducing the final build size. We ensure that these dependencies will be served correctly, so don't worry 😉.

Along with this configuration, the validation explained earlier takes place.

See below the difference in the size of the production build:

With FrontHub CommonsWithout FrontHub Commons
Build with commonsBuild without commons
.js gzip: 40.78 kB.js gzip: 122.76 kB
.js: 127.5 kB.js: 388.5 kB

In this example, the user will download an MFE that is three times smaller, loading the common resources only once. Recalling the previous example, regardless of the number of micro frontends being loaded on the screen, the common dependencies will be downloaded only once!

Versions of common libraries​

Commons is a library that is also versioned. Therefore, it is essential to know which version of the @resultadosdigitais/front-hub-commons library is being used to understand which versions of the common dependencies are available. See the table below for the available versions:

@resultadosdigitais/front-hub-commons
>=4.x <=11.x >=12.x
"axios": "0.21.1"
"clsx": "1.1.1"
"i18next": "19.8.4"
"numeral": "2.0.6"
"react": "17.0.1"
"react-dom": "17.0.1"
"react-hook-form": "6.14.0"
"react-i18next": "11.8.5"
"react-is": "17.0.1"
"react-router-dom": "5.2.0"
"redux": "4.0.5"
"regenerator-runtime": "0.13.3"
"styled-components": "5.2.1"
"uuid": "3.4.0"
"axios": "0.21.1"
"clsx": "1.1.1"
"i18next": "19.8.4"
"numeral": "2.0.6"
"react": "18.3.1"
"react-dom": "18.3.1"
"react-hook-form": "6.15.0"
"react-i18next": "11.8.6"
"react-is": "18.3.1"
"react-router-dom": "5.3.0"
"redux": "4.0.5"
"regenerator-runtime": "0.13.3"
"styled-components": "6.1.13"
"uuid": "3.4.0"
info

Always keep an eye on the changelog for changes in the front-hub releases to stay updated on any changes.