DEV Community: Matthew Waldron

Supercharge your Build Tooling

Matthew Waldron — Tue, 15 Nov 2022 17:58:23 +0000

Have you ever wondered if there was an easier way to manage your tooling across projects?

With so many tools in the frontend ecosystem to set up, it can be really time consuming and difficult to manage everything; taking time away you could be spending on actual development.

In this series, we'll cover approaches for managing tooling and how you can implement this yourself to increase your productivity. I'll be using my own personal setup throughout the series as a reference.

Frontend Tooling

Before we dive in, let's consider popular tooling a developer will need for frontend projects and how important it will be to manage them more efficiently.

Git Hooks help automate the development lifecycle and tools like Husky help make setting this up easier across different systems.
Tools like Commitizen help standardize commit message rules with user friendly prompts and Commitlint to lint commit messages
Lint-Staged helps automate code linting on changed files after commits
Stylelint lints styling, Postcss provides a variety of plugins to transform css, and Sass helps scale css with helpful features.
TypeScript provides type-safety for projects
Eslint lints your JavaScript and TypeScript code.
Prettier enforces consistent styling and across your entire codebase and provides linting
Jest is a popular testing framework
Browserslist defines your supported browsers/devices
Secretlint helps prevent accidently committing credentials
Tools like HTMLHint and Markdownlint lint html and md files
Semantic Release automates versioning and publishing

That was a lot! But our tooling isn't limited to the list above. You might be using a framework or a completely different setup that will require its own set up of tools which is why it's important to think of ways to make managing this easier.

Extendable Configurations

Luckily for us, many of the tools above provide ways to create our own custom configurations and extend them by reference.

For example, we might define our own eslint configuration:

index.js

module.exports = {
    // my custom eslint setup
}

But how do we reference this in our own projects? We'll want to publish this somewhere like npm so we can download anywhere and install in our project.

In our project's .eslintrc.js file we can define our configuration like so:

.eslintrc.js

module.exports = {
    extends: '@[unique-scoped-name]/eslint-config',
};

See eslint's guide for more information.

Versioning and Publishing

So far so good, but what if we need to make a change to our shareable configuration? We'll don't want to manually bump our package.json version and manually publish out to npm.

Let's automate! We can use a tool like semantic-release to do this for us:

.github/workflows/release.yml

...
- name: Release
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: npx semantic-release

And in our .releaserc.json file:

.releaserc.json

{
    "plugins": [
        "@semantic-release/commit-analyzer",
        "@semantic-release/release-notes-generator",
        "@semantic-release/changelog",
        "@semantic-release/npm",
        "@semantic-release/github",
        "@semantic-release/git"
    ],
    "branches": "main"
}

In this setup, we have semantic release automating versioning, publishing to npm, and changelog generation to help us keep track of changes.

Monorepos

For publishing one or two packages, this setup works well. But what if we have several configurations to maintain? This setup will be hard to scale. We'll need to rethink our approach.

This is where monorepos come to save the day. A monorepo is like a regular repo, except that it can hold many projects. If we have a lot of configurations we can keep and maintain them in the same repository.

What if we want to automate versioning and publishing? Using semantic-release won't work in a monorepo setup. But with a monorepo tool like Lerna we can leverage it to version and publish multiple changed packages.

We can also use a tool called Yarn Workspaces to optimize and link different packages together. While Lerna can do this too, Yarn Workspaces offers improved performance.

Conclusion

After reviewing our options, a more ideal setup for managing multiple configurations involves using a monorepo structure to manage, version, and publish our packages.

A common monorepo structure for our configurations will look like the following:

/
    .github/
        # github CI/CD files
    packages/
        eslint-config/
        stylelint-config/
        ...
    package.json
    lerna.json
    ...

In part 2 of this series, we'll go into detail on how to set up this repository. I'll be basing this off my own personal shareable configuration monorepo. Follow for updates on new article releases!

Module Federation for Enterprise (Part 2)

Matthew Waldron — Sun, 17 Apr 2022 18:29:33 +0000

Part 1 in my series Module Federation for Enterprise covered an approach to support multiple testing environments and eliminate hard-coded URLs from webpack configurations.

Despite the benefits, the approach we covered introduces a lot of complexity. It requires a lot of scaffolding, knowledge of Webpack internals, and an understanding of the project that is counterintuitive to more streamlined approaches.

But what if there was an easier way? Luckily, there is! In this guide, we'll use a new technique to simplify a multi-environment module federation setup.

Before We Begin

It is important to mention current options first that might suit your requirements better:

Module Federation supports promise-based logic to infer the remotes at runtime. This is useful for dynamically inferring the path and versioned remotes. You can see an example in the Webpack documentation and additionally via Zack Jackson's comment on my blog post.

Another common approach is to use .env variables and/or plugins like EnvironmentPlugin for different environments. This is a great option for many use-cases. An example of dynamic remotes with runtime environment variables can be found on the Module Federation examples repository.

High Level Overview

This guide will use Webpack's NormalModuleReplacementPlugin to infer the remote URL at runtime for multiple environments. We'll cover what this plugin is, the advantages of using it, and go over code to help us set up our remotes at runtime.

Note: This guide will include only essential code snippets relevant to the discussion of this approach. A complete working example of what we'll cover can be found in my module-federation-template repository.

Project Structure

Here is a basic overview of our project structure:

The public/ and src/ directories will hold our code and assets. The configs/ directory will hold our webpack configurations. And lastly, the environments/ directory will hold our module federation URLs. More on that below.

| Module Federation Monorepo
| -----------
| packages/
|   host/
|       configs/
|       environments/
|       public/
|       src/
|           bootstrap.js
|           app.js
|           init-remote.js
|   remote/
|       configs/
|       public/
|       src/
|           bootstrap.js
|           app.js

The `NormalModuleReplacementPlugin`

According to the Webpack docs:

The NormalModuleReplacementPlugin allows you to replace resources that match resourceRegExp with newResource. If newResource is relative, it is resolved relative to the previous resource. If newResource is a function, it is expected to overwrite the request attribute of the supplied resource.

In other words, we can replace a module with another module if our regex condition matches. In our case, we want to use this plugin to swap files dependent on a webpack variable we supply to our script in package.json.

First we'll create two files in the environments/ directory called dev and prod. FormApp is the scope of our remote app and the value is the remote URL.

dev.js

export default {
  FormApp: "http://localhost:3001",
};

prod.js

export default {
  FormApp: "https://module-federation-template-remote.netlify.app",
};

Next, we'll create a file called init-remotes.js under src/ with the following import and log out the URL of FormApp:

init-remotes.js

import config from "../environments/TARGET_ENV";

console.log(config.FormApp);

Next, we'll pass in a Webpack variable called TARGET_ENV and assign it a value that matches the same name of the files we created in the previous step (TARGET_ENV=dev and TARGET_ENV=prod):

package.json

  "scripts": {
    "dev": "webpack serve --env development TARGET_ENV=dev --config config/webpack.dev.js",
    "build": "webpack --env production TARGET_ENV=prod --config config/webpack.prod.js"
  },

In our Webpack configuration, we can access this variable and assign a default fallback value like so:

webpack.common.js

const targetEnv = env.TARGET_ENV || "prod";

Lastly, we'll import and use NormalModuleReplacementPlugin to use the appropriate environment module.

webpack.common.js

const webpack = require("webpack");

const commonConfig = (isProduction, env) => {
  const targetEnv = env.TARGET_ENV || "prod";

  return merge([
    {
      plugins: [
        new webpack.NormalModuleReplacementPlugin(
          /(.*)TARGET_ENV(\.*)/,
          (resource) => {
            resource.request = resource.request.replace(
              /TARGET_ENV/,
              `${targetEnv}`
            );
          }
        ),
      ],
    },
  ]);
};

module.exports = commonConfig;

What we're doing here is using regex to match TARGET_ENV. During runtime, NormalModuleReplacementPlugin will match this resource via the import import config from '../environments/TARGET_ENV'; we added in init-remotes.js and will replace the TARGET_ENV portion of the import with targetEnv which is the value of the environment variable we passed in via our scripts in package.json.

For example, for development builds at runtime, the import in init-remote.js will become:

import config from "../environments/dev";

And will successfully log the dev URL:

http://localhost:3001

That's pretty cool! With this method we can easily add in more remotes and add additional files to support more testing environments. I personally like this method over .env files and associated plugins. It gives me a clean way to support many environments and reduces conditional logic in my webpack configurations.

Code for Initializing Dynamic Remotes

Now that we have multi-environment support, we'll need to add in some code to initialize our remotes dynamically for us to use in the host app.

Let's break this down into several steps:

Create <script> tags that will bootstrap our remotes.
Connect to the remote containers dynamically at runtime.
Load the default module of our remote.
Create a function to handle the previous three steps.

So far we have our environment setup in init-remote.js:

import config from "../environments/TARGET_ENV";

We'll add code to create the script tags. We resolve a promise if the script tag was successfully created after onload.

The endpoint parameter is the remote URL that will be passed in like this: setRemoteScript(config['FormApp']). We're using the config from our environment import and the remote scope FormApp as a key/value pair to retrieve the corresponding URL from environments/dev.js file for development builds, etc.

const setRemoteScript = (endpoint) =>
  new Promise((resolve) => {
    const remoteUrlWithVersion = `${endpoint}/remoteEntry.js`;
    const script = document.createElement("script");
    script.src = remoteUrlWithVersion;
    document.head.appendChild(script);
    script.onload = () => resolve();
  }).catch((err) => {
    console.log(err, `Error setting script tag for ${module}.`);
  });

Note: If you have versioned remotes, you can substitute the remoteUrlWithVersion variable with the following code from the second example from the Webpack docs and modify to suit your needs:

const setRemoteScript = (endpoint) =>
  new Promise((resolve) => {
    const urlParams = new URLSearchParams(window.location.search);
    const version = urlParams.get("appVersionParam");
    const remoteUrlWithVersion = `${endpoint}${version}/remoteEntry.js`;
    const script = document.createElement("script");
    script.src = remoteUrlWithVersion;
    document.head.appendChild(script);
    script.onload = () => resolve();
  }).catch((err) => {
    console.log(err, `Error setting script tag for ${endpoint}.`);
  });

Next we'll need to dynamically connect to the remote containers. We'll copy/paste the code found on the Webpack docs.

The scope and module will be passed in like so: loadComponent('FormApp', './initContactForm')

const loadComponent = (scope, module) => {
  return async () => {
    await __webpack_init_sharing__("default");
    const container = window[scope];
    await container.init(__webpack_share_scopes__.default);
    const factory = await window[scope].get(module);
    const Module = factory();
    return Module;
  };
};

Next we'll write a small function to get us the default module of our remote.

The remote parameter will be the returned value from loadComponent.

const loadModuleFrom = (remote) => {
  remote()
    .then((module) => module.default())
    .catch((err) => {
      console.log(err, `Error loading default module from ${remote}.`);
    });
};

And finally, we'll create a function to handle all the steps to get our remotes.

const initRemote = (remoteScope, remoteModule) => {
  setRemoteScript(config[remoteScope])
    .then(() => {
      const loadedComponent = loadComponent(remoteScope, remoteModule);
      loadModuleFrom(loadedComponent);
    })
    .catch((err) => {
      console.log(
        err,
        `Error initializing ${remoteModule} from ${remoteScope}.`
      );
    });
};

Altogether our code should look like the following:

init-remote.js

import config from "../environments/TARGET_ENV";

const setRemoteScript = (endpoint) =>
  new Promise((resolve) => {
    const remoteUrlWithVersion = `${endpoint}/remoteEntry.js`;
    const script = document.createElement("script");
    script.src = remoteUrlWithVersion;
    document.head.appendChild(script);
    script.onload = () => resolve();
  }).catch((err) => {
    console.log(err, `Error setting script tag for ${endpoint}.`);
  });

const loadComponent = (scope, module) => {
  return async () => {
    await __webpack_init_sharing__("default");
    const container = window[scope];
    await container.init(__webpack_share_scopes__.default);
    const factory = await window[scope].get(module);
    const Module = factory();
    return Module;
  };
};

const loadModuleFrom = (remote) => {
  remote()
    .then((module) => module.default())
    .catch((err) => {
      console.log(err, `Error loading default module from ${remote}.`);
    });
};

const initRemote = (remoteScope, remoteModule) => {
  setRemoteScript(config[remoteScope])
    .then(() => {
      const loadedComponent = loadComponent(remoteScope, remoteModule);
      loadModuleFrom(loadedComponent);
    })
    .catch((err) => {
      console.log(
        err,
        `Error initializing ${remoteModule} from ${remoteScope}.`
      );
    });
};

export default () => initRemote;

Now it's time to start using our remote app! In app.js, we can use the following code to lazy load it:

app.js

import(/* webpackChunkName: "FormApp" */ "./init-remote")
  .then((module) => {
    const initRemote = module.default();
    initRemote("FormApp", "./initContactForm");
  })
  .catch((err) => {
    console.log(err, "Error initializing lazy loaded remote.");
  });

We're loading the default module of init-remote.js which is initRemote; the function we created to handle all the steps for loading our remotes. Supply the remote scope name and the remote module key value to initRemote and now you're all set to start using the remote app!

A complete working example of this setup can be found on my module-federation-template repository.

Details on my personal setup:

In remote, I'm using the Module Federation Live Reloading Plugin to hot reload my remote app via @module-federation/fmr.
In host, I'm using the Automatic Vendor Federation Plugin to easily manage shared dependencies via @module-federation/automatic-vendor-federation.

Important configuration notes on my personal setup:

Use an asynchronous boundary to load all your code by dynamically importing your app.js in a separate file and then reference that file as your main entrypoint.
If you're using Webpack SplitChunks, make sure your chunks are set to async and your cacheGroups names are unique between host and remote(s).

Conclusion

Thank you for reading! I hope you find this approach of supporting multiple environments for Module Federation useful.

To summarize, we used NormalModuleReplacementPlugin to load in the appropriate environment configuration file at runtime. We also added code to dynamically load our remotes to use in our host app.

Advantages:

NormalModuleReplacementPlugin helps reduce conditional logic over .env files for setups with many environments
NormalModuleReplacementPlugin is built into the Webpack core library, so no reliance on third-party plugins
Using Webpack variables to set the environment can be easily integrated into your build pipeline
Project setup can be easily scaled to support multiple remotes and environments
Project setup is less complex than the original implementation I covered in Part 1 of this blog series

A complete working example of this setup can be found on my module-federation-template repository.

Please like and share if you found this article useful. Also please leave a comment with your thoughts and what your favorite approach is for setting up your Module Federation projects!

8 Must-Have GitHub Repos for Front-end Developers

Matthew Waldron — Mon, 11 Apr 2022 00:01:44 +0000

One of the most challenging aspects of front-end development is maintaining configurations and dependencies used in the projects. In this guide, we will cover essential repository tips and tricks to help set up your tools, automate your workflow, and standardize your projects. At the end, we'll use everything we've covered to market your skills.

Why Write This Article?

This is the article I wish I had when I started front-end development. I've gone through countless ways of how to best organize and maintain my projects. This article is the result of much learning and experimentation that has culminated in an efficient workflow that is useful for me and I hope that it can be useful for you too.

Note: While this article is for beginners, I do cover a lot of advanced topics that are covered quickly at a very high level. Don't feel discouraged if you don't understand everything right away. It's okay! Remember to take everything step-by-step.

Prerequisites

If you haven't created a GitHub account yet, you can follow the link here to get started.

Before we begin, I recommend learning Git version control; an essential tool to manage your code and track changes. More information can be found here. A cheat sheet can be found here that covers the bulk of commands you'll use on a regular basis starting out.

1. The Dotfiles Repository

If you've started working on projects, you've likely come across files like .gitignore, .editorconfig, etc.

The .gitignore file contains a list of files/directories you want ignored from version control. The .editorconfig file contains configurations to maintain consistent coding styles between code editors.

For me personally, these files don't change often from project to project. I want a way to store these files, copy them easily to new projects, and maintain them using version control.

The simplest solution is to create a regular repository and commit the dotfiles to GitHub. Simply copy/paste the files to a new project when you want to use them. In some cases, however, other dotfiles might get read by tools in a specific directory; commonly your home directory on your machine.

For these situations, it might be useful to create a bare repository. A bare repository is a repository that contains only the .git folder; the folder containing version control history while a regular git repo contains both the .git and project files.

Why is this important? With a bare repository, we can leave the dotfiles where they are so that they'll get picked up by tools that use them while our version control history lives in a separate folder.

Want to create your own? You can follow the directions here in my personal dotfiles repo. I have instructions to set up for linux, mac, and windows systems. If you run into issues with my directions, please submit an issue!

In my personal dotfiles, I opted to keep things relatively simple. I have a .gitignore, a global gitignore, .editorconfig, a default MIT LICENSE I use for projects, and a basic README template. I also use a simple script to automate my bare repo commands and file copying.

There are a near-infinite number of ways to configure your own dotfiles. In fact, there is a huge community built around them. This dotfiles resource is your one-stop guide for everything dotfiles.

2. The `.extra` Repository

Popularized by this css-tricks article, the .extra repository is useful for hiding information you don't want to share publicly in one/several files in a private repo.

Examples of files you might consider making private include .gitconfig which contains sensitive information such as your personal email. If this file was in your public .dotfiles repository and someone forked and used it, they could accidentally commit changes as you.

In my personal .extra repo I have my .gitconfig and a resume file containing contact information I don't want public.

Keep in mind that these files won't benefit from your main .dotfiles setup, but more importantly, your sensitive configurations will be protected.

3. The `.github` Repository

When creating repositories, it's important to include community files which are a standard set of files that provide additional context, help, and safety to users or collaborators. You may have already seen examples of these files in other projects such as CONTRIBUTING and CODE_OF_CONDUCT. More information on community health files can be found here.

Creating a new GitHub repository and naming it .github creates a special repository where you can add default community health files for your repositories.

Once created, GitHub will automatically apply these files from the .github repo to all current and future public repositories. You can override this behavior on specific repositories if you create a community health file with the same name in the same directory.

You can easily create these community health files using the amazing github template generator for your .github or generate for individual repositories.

My personal .github repositories uses modified files from that generator tool. When I go to the Insights tab, then Community Standards tab on the left on my public repositories, I can see that my files meet GitHub's recommended community standards found here.

4. The Shareable Config Monorepo

One of the largest challenges in front-end development is managing dependencies and tooling configurations for projects. For example, you might use linters such as prettier, eslint, stylelint, and commitlint to help your code and commits conform to best practices.

Additional tools such as Browserslist, a tool to define which browsers are supported, Postcss, a tool to automate CSS operations, Jest, a JavaScript testing framework, TypeScript, a superset of JavaScript that adds static typing, Webpack, a JavaScript module bundler, and many others; all use configurations that can introduce a fair amount of complexity and time to set up for projects.

You can create your own shareable configurations to make this process easier. The idea centers around identifying your most commonly used settings for each tool and publish your own package to the NPM registry so you can install it in projects. Check out this guide to learn how. This is great, but if we have a lot of tools to set up and publish individually to NPM, this creates a lot of overhead to maintain.

Here's where the monorepo comes in. A monorepo is just like a regular repository, except that it holds many individual projects. Monorepos are an ideal tool to use because you can manage all of your configurations in one place. A good introductory article on the subject can be found here.

My shareable-configs repository is a monorepo of all my shareable configurations for projects. I use Lerna and Yarn Workspaces to optimize my workflow and dependency management between packages. Lerna and GitHub Actions are used in conjunction to automatically version and deploy to the NPM registry and create GitHub releases. GitHub actions is also used to automate dependency updates and discover vulnerabilities. In each shareable configuration, I have a postinstall script that will auto-generate configuration files after I install them. You can fork and use my monorepo for your own shareable configs.

5. The Mighty Template Repository

So far, we've covered how to manage dotfiles, standardize community guideline files, and automate management of shareable configurations.
We'll use everything we've created to set up a repository we can use as a template for new projects. After you're done, enable the setting Template Repository under the Settings section of your repository so you can create new projects in GitHub using the template you created.

You can check out / use my personal Webpack Template. It is a comprehensive repository with server and serverless builds for Express and Netlify with automatic linting, versioning, GitHub releases, vulnerability scanning, and dependency management.

6. The Personal Portfolio Repository

No GitHub profile would be complete without your own personal website to show off your skills. With a lot of the hard work out of the way, we can create a new repository using the new template created in the previous step.

The rest is up to you! Your personal portfolio is a great way to showcase your skills in a unique way.

You can check out my personal portfolio as an example that uses my webpack template as a base. I use Netlify for hosting. Every time I make an update and deploy to my main branch, Netlify will run my build script and publish changes automatically.

7. The Resume Repository

I've spent countless hours on resume formatting over the years. After researching how to automate this process I discovered jsonresume, an open source initiative to create JSON-based resumes. Simply create a .json file containing your resume information, install the resume-cli package, pick a theme, and then watch your resume generate into .html or .pdf automatically.

My personal resume repository uses a modified version of the onepage theme where I added support for a Certifications section. I also have an untracked file containing private contact information which is backed up on my private .extra repository.

8. The GitHub `README.md` Repository

Now that you've created your personal portfolio and resume, you should have a good idea of how you can best summarize your skills and accomplishments to recruiters. A good way to do this is to create a GitHub repository using the same name as your GitHub account name. This will unlock a special repository that will be viewable on your GitHub profile.

Have fun with this and show the world what you can do! You can see my personal readme in action here. For inspiration, check out this awesome collection of readme repositories.

Conclusion

That's it! I hope you enjoyed the article. You can find examples of the repositories covered on my GitHub.

Tutorial - A Guide to Module Federation for Enterprise

Matthew Waldron — Sat, 07 Aug 2021 03:41:00 +0000

Update: 4/17/2022

See Part 2 of my Module Federation for Enterprise series for a much easier way to implement a multi-environment setup than the approach described below.

Update: 9/11/2021

Hard coded URLs and environment variables can be avoided completely. See Zack Jackson's comment below illuminating the usage of promise new Promise to infer the remote at runtime.

An Approach to Module Federation for Enterprise

Who is this Guide For?

If you are part of an organization that has the following requirements, this guide may be of interest:

Multiple development environments (local, dev, staging, prod, etc.)
Multiple applications shared across multiple domains (URLs)

Introduction

Advantages

Module Federation is an exciting new addition to Webpack 5. As described by its creator Zack Jackson:

Module Federation allows a JavaScript application to dynamically load code from another application and in the process, share dependencies.

This powerful orchestration micro-frontend architecture will make it easier for organizations to decouple their applications and share across teams.

Limitations

Despite Module Federation's advantages, we can see limitations when applying this to organizations with more complex environment requirements.

Let's look at the following example:

webpack.dev.js

new ModuleFederationPlugin({
  remotes: {
    FormApp: "FormApp@http://localhost:9000/remoteEntry.js",
    Header: "Header@http://localhost:9001/remoteEntry.js",
    Footer: "Footer@http://localhost:9002/remoteEntry.js",
  },
  ...
}),

webpack.prod.js

new ModuleFederationPlugin({
  remotes: {
    FormApp: "FormApp@http://www.formapp.com/remoteEntry.js",
    Header: "Header@http://www.header.com/remoteEntry.js",
    Footer: "Footer@http://www.footer.com/remoteEntry.js",
  },
  ...
}),

The first thing you may notice is that the URLs are hard-coded in the Webpack configuration. While this setup works, it won't scale well if there are multiple apps distributed across multiple environments.

Another consideration is code deployment. If a remote app URL changes, teams must remember to change both the remote app and host app configurations. Changes required on multiple files in different projects increase the likelihood of mistakes occurring and code breaking in production.

Conclusion

We need a way to dynamically assign the appropriate environment context for both local and remote entrypoints. However, abstracting out logic for assigning environment context will prevent Module Federation from knowing where and how to load remote containers during the Webpack build process; as absolute URL paths will no longer exist in Webpack configurations. We'll need to be able to load remote apps dynamically when environment context has been established.

High Level Overview

This repository employs the modification of several documented techniques to support a fully dynamic, multi-environment setup.

MutateRuntimePlugin.js

This plugin by Module Federation Author Zack Jackson allows for tapping into the Webpack MutateRuntime compilation hook to mutate publicPath dynamically.

This code snippet by devonChurch is an implementation of MutateRuntimePlugin.js where publicPath is intercepted and mutated via variable assignment initialized during runtime.

Multi-Environment Architecture

This discussion thread and code example by devonChurch outlines a method for injecting local and remote entrypoints at runtime through publicPath mutation via the method described above.

This method also employs the use of .json configuration files which hold a global mapping of all local and remote entrypoint URLs and the current environment.

Dynamic Remote Containers

This code snippet via Webpack documentation describes exposed methods for initializing remote containers dynamically at runtime.

Webpack Configurations

When implementing the documented techniques above, I encountered several gotchyas when setting up more advanced Webpack configurations. I documented these issues and fixes so you can avoid these pitfalls.

Project Setup

Before diving in to the project code, let's discuss briefly, the project's structure and underlying configurations.

| dynamic-container-path-webpack-plugin (dcp)
| -----------

| Shared Configs
| -----------
| map.config.json
| bootstrap-entries.js

| Host / Remote
| -----------
| chunks.config.json
| * environment.config.json
| webpack.common.js
| webpack.dev.js
| webpack.prod.js
| index.html

| Host
| -----------
| bootstrap.js
| load-component.js

| Remote
| -----------
| bootstrap.js

dynamic-container-path-webpack-plugin

My modified version of MutateRuntimePlugin.js that mutates publicPath at runtime. This can be installed from npm and can be used as a plugin and customized in your Webpack configuration.

Shared Configs

map.config.json contains a global object of local and remote endpoint URLs.

bootstrap-entries.js bootstraps Webpack chunks with the correct URLs based on the current environment.

Host / Remote

chunks.config.json is an array of Webpack entrypoints required for application initialization and remote application namespaces for consumption.

environment.config.json is a key/value pair indicating the current environment. This can be set by your build pipeline. However, for simplicity, we will set the environment in bootstrap-entries.js in this tutorial.

Webpack configuration files employ webpack-merge so we can reduce Webpack boilerplate code (loaders, common Webpack environment configurations, etc.). This is an architecture choice recommended for streamlining configurations across applications.

index.html will include a script reference to bootstrap-entries.js so that it can bootstrap Webpack chunks at runtime so it can load our federated modules.

Host

bootstrap.js serves as an asynchronous barrier for our local and remote code. This is a required file in order for Module Federation to work correctly. You can read more about this here. We'll also set up logic here to lazy-load our remote app.

load-component.js is code directly lifted from Webpack documentation as referenced in this guide under Dynamic Remote Containers. This file will dynamically load and negotiate shared libraries of our remote app with the host.

Remote

Similarly to Host, bootstrap.js serves as an asynchronous barrier for our local and remote code.

Mutating publicPath via Global Variable Assignment

Discussions on `publicPath` Assignment Options

Our first step is to identify a method for dynamically mutating publicPath. Before reviewing the solution, let's briefly discuss our options by navigating to the Webpack docs.

We could use DefinePlugin to set environment variables to modify publicPath, however, we won't be able to easily scale over several remotes with several environments.

A promising option involves leveraging Webpack's publicPath: auto to automatically determine the value from context (for example: document.currentScript). We can even this in action in Zack Jackson's dynamic remotes example repo.

While this option does meet our desired requirements of removing the hardcoded URL's from the webpack configuration, unfortunately, now we need to define the remote paths inside the host via App.js, thus defeating the intended purpose of keeping hardcoded URL's out of our code. Another drawback prevents us from using style-loader because it relies on a static publicPath to embed styles inline in the html. See this GitHub issue thread.

This leaves us our last option which involves modifying publicPath on the fly. In the next section we'll discuss how to tap into one of Webpack's complication hooks and write a custom Webpack plugin that supports custom mutation of publicPath during runtime.

Outsourcing logic to runtime reduces hard-coded Webpack build configurations, reduces maintenance, and increases configuration re-usability.

High Level Overview

We can mutate publicPath by referencing and modifying a custom Webpack plugin by Module Federation Author Zack Jackson that uses the MutateRuntime compilation hook to mutate publicPath dynamically.

First let's take a look at the completed plugin's API:

const  DynamicContainerPathPlugin =
    require('dynamic-container-path-webpack-plugin');
const  setPublicPath =
    require('dynamic-container-path-webpack-plugin/set-path');

 new DynamicContainerPathPlugin({
   iife: setPublicPath,
   entry: 'host',
 }),

DynamicContainerPathPlugin accepts two arguments. iife is an immediately invoked function expression that will take in entry as it's argument.

When iife is executed inside the plugin, it will use entry as a key to find the correct environment. When iife is returned, DynamicContainerPathPlugin will assign the resulting value to Webpack's internal publicPath variable.

Tapping into `PublicPathRuntimeModule`

Let's look under the hood to see how the dynamic-container-path-plugin works.

Note: This guide assumes basic anatomy of how a Webpack plugin works. To read more, reference the Webpack docs found here.

First we call apply(compiler) to access Webpack's compilation lifecycle:

apply(compiler) {

};

Next, we'll need a way to intercept Webpack before finishing the compilation. We can do this using the make hook:

compiler.hooks.make.tap('MutateRuntime', compilation => {});

Within the make hook, we have access to Webpack's compilation hooks that allow us to create a new build. We can use the runtimeModule hook that will allow us to tap directly into publicPath assignment and call a custom method changePublicPath to allow for dynamic publicPath re-assignment:

compilation.hooks.runtimeModule.tap('MutateRuntime', (module, chunk) => {
  module.constructor.name === 'PublicPathRuntimeModule'
      ? this.changePublicPath(module, chunk)
      : false;
  });
});

`changePublicPath` Method

changePublicPath calls two methods. The first method getInternalPublicPathVariable strips out publicPath's value using Webpack's internal global variable __webpack_require__.p set at build time and returns the internal variable only.

getInternalPublicPathVariable(module) {
  const [publicPath] = module.getGeneratedCode().split('=');
  return [publicPath];
}

The second method setNewPublicPathValueFromRuntime accepts the internal publicPath variable __webpack_require__.p derived from getInternalPublicPathVariable as an argument. The variable is re-assigned a value using custom logic provided to the Webpack plugin.

The new publicPath value is then assigned to module._cachedGeneratedCode which is equal to __webpack_require__.p, our internal Webpack publicPath variable, at build time.

setNewPublicPathValueFromRuntime(module, publicPath) {
  module._cachedGeneratedCode =
    `${publicPath}=${this.options.iife}('${this.options.entry}');`;
  return  module;
}

`iife` and `entry`

In the previous section we covered how the method setNewPublicPathValueFromRuntime assigns the new publicPath value. In this section we'll cover the logic contained in iffe:

`${publicPath}=${this.options.iife}('${this.options.entry}');`;

Let's zoom out again to our original API setup using DynamicContainerPathPlugin.

const DynamicContainerPathPlugin =
    require('dynamic-container-path-webpack-plugin');
const setPublicPath =
    require('dynamic-container-path-webpack-plugin/set-path');

 new DynamicContainerPathPlugin({
   iife: setPublicPath,
   entry: 'host',
 }),

DynamicContainerPathPlugin comes with logic for assigning publicPath via setPublicPath, but you can modify to fit your own needs.

dynamic-container-path-webpack-plugin/set-path contains the following code:

module.exports = function (entry) {
  const { __MAP__, __ENVIRONMENT__ } = window;
  const { href } = __MAP__[entry][__ENVIRONMENT__];
  const publicPath = href + '/';
  return publicPath;
};

__MAP__ and __ENVIRONMENT__, which will be covered later, are global variables we will set up at runtime. These global variables values will be assigned the fetched data from our json mapping of URLs (covered below).

entry is used as a key to look up the current entrypoint in __MAP__. href is the resulting value extracted from __MAP__ and assigned to publicPath, which in turn, is assigned to Webpack's internal publicPath variable as we covered in the last section.

Creating a Global Mapping of Endpoints

One disadvantage, as outlined earlier, is Module Federation's dependence on hard-coded URLs that scale poorly with more complex organizational requirements. We will instead define a json object containing a global reference of host and remote entrypoint URLs that will be referenced by the repositories.

{
  "Host": {
    "localhost": {
      "href": "http://localhost:8000"
    },
    "production": {
      "href": "https://dynamic-host-module-federation.netlify.app"
    }
  },
  "RemoteFormApp": {
    "localhost": {
      "href": "http://localhost:8001"
    },
    "production": {
      "href": "https://dynamic-remote-module-federation.netlify.app"
    }
  }
}

Hostand RemoteFormApp refers to the Webpack entrypoint names we will define later in our repositories.

Each of these entrypoints contain environment URLs; the key referring to the environment name and property href containing the hard-coded URL.

Writing a Script to Bootstrap Chunks

The key to supporting a multi-environment setup is by dynamically assigning the appropriate endpoint URLs based on the current environment at runtime.

We'll create a file called bootstrap-entries.js that will be tasked with the following:

Fetch configuration files and assign them to global variables to be used by dynamic-container-path-webpack-plugin to mutate publicPath
The configuration files and newly defined publicPath will inject local and remote chunks on the page.

Initial Setup

First we'll define an iife so that it will execute immediately in index.html:

(async () => {
  // our script goes here
})();

Next we'll set up logic to determine the current environment:

Note: Refer to the code snippets in section A Quick Note on environment.config.js for a build pipeline configuration.

const environment = () =>
  location.host.indexOf('localhost') > -1 ? 'localhost' : 'production';

Since we'll be referencing configuration files relative to individual repositories, we have a small function to get the appropriate base path:

const getBasePath = environment() == 'localhost' ? './' : '/';

Next, we'll fetch a file called assets-mainfest.json.

For production builds, assets are commonly cache-busted through the use of Webpack's contentHash feature. This file will get generated by webpack-assets-manifest and will allow us to fetch our chunks without needing to know the dynamically generated contentHash value assigned with each production build:

const getManifest = await fetch('./assets-manifest.json').then(response =>
  response.json()
);

Next, we will define a const array of configuration files:

const configs = [
  `https://cdn.jsdelivr.net/gh/waldronmatt/
        dynamic-module-federation-assets/dist/map.config.json`,
  `${getBasePath}chunks.config.json`,
];

The first configuration references the global mapping of endpoints we defined earlier.

Note: I'm using jsdeliver to serve map.config.json and bootstrap-entries.js so the repositories can reference from one place. Look into more robust cloud alternatives for mission critical applications.

The second configuration is an array of entrypoints required for application initialization and remote application namespaces for consumption. This is unique per repository and will be covered later on.

Fetch Configurations and Assign to Global Variables

Now that our utility functions and configuration file references are defined, the next step is to fetch our configurations and assign them to globally defined variables.

First we'll fetch the configuration files in parallel. We want to ensure all of the configurations are fetched before variable assignment:

const [map, chunks] = await Promise.all(
  configs.map(config => fetch(config).then(response => response.json()))
);

Next we'll assign environment and map to global variables. This step is critical, as it is used by dynamic-container-path-webpack-plugin to re-assign the value of publicPath.

window.__ENVIRONMENT__ = environment();
window.__MAP__ = map;

Fetch JavaScript from `entrypoints` and Inject on the Page

Lastly, we'll loop through each chunk defined in chunks.config.js and return the code:

Note: As we'll see later in the section, chunks.config.js contains two arrays containing name references to local and remote Webpack chunks.

First we're getting all local chunks and returning the code. Because webpack-assets-manifest doesn't generate an entry for remoteEntry.js (a file used by Module Federation to bootstrap remotes), we will fetch it by name only.

Note: remoteEntry.js is considered a local chunk in the remote repository.

...chunks.entrypoints.map(chunk => {
    return chunk !== 'remoteEntry'
        ? fetch(`./${getManifest[`${chunk}.js`]}`)
            .then(response => response.text())
        : fetch(`${chunk}.js`).then(response => response.text());
}),

Next, we're getting all remote chunks and returning the code. First we grab the appropriate endpoint for each chunk based on the current environment.

Then we use the derived endpoint value and assign it to remoteEntry.js so we can properly fetch the remotes.

...chunks.remotes.map(chunk => {
    const { href } = map[chunk][environment()];
    return fetch(`${href}/remoteEntry.js`).then(response => response.text());
}),

Lastly, for each chunk we create a script tag, assign the returned code to it, and append it to the page for execution.

.then(scripts =>
    scripts.forEach(script => {
        const element = document.createElement('script');
        element.text = script;
        document.querySelector('body').appendChild(element);
    })
);

Altogether, our code should look like the following:

(async () => {
  const environment = () =>
    location.host.indexOf('localhost') > -1 ? 'localhost' : 'production';

  const getBasePath = environment() == 'localhost' ? './' : '/';

  const getManifest = await fetch('./assets-manifest.json').then(response =>
    response.json()
  );

  const configs = [
    `https://cdn.jsdelivr.net/gh/waldronmatt/
        dynamic-module-federation-assets/dist/map.config.json`,
    `${getBasePath}chunks.config.json`,
  ];

  const [map, chunks] = await Promise.all(
    configs.map(config => fetch(config).then(response => response.json()))
  );

  window.__ENVIRONMENT__ = environment();
  window.__MAP__ = map;

  await Promise.all([
    ...chunks.entrypoints.map(chunk => {
      console.log(`Getting '${chunk}' entry point`);
      return chunk !== 'remoteEntry'
        ? fetch(`./${getManifest[`${chunk}.js`]}`).then(response =>
            response.text()
          )
        : fetch(`${chunk}.js`).then(response => response.text());
    }),
    ...chunks.remotes.map(chunk => {
      const { href } = map[chunk][environment()];
      return fetch(`${href}/remoteEntry.js`).then(response => response.text());
    }),
  ]).then(scripts =>
    scripts.forEach(script => {
      const element = document.createElement('script');
      element.text = script;
      document.querySelector('body').appendChild(element);
    })
  );
})();

Later, we'll cover how to implement the code in our repositories.

A Note on `environment.config.js`

For simplicity, we will define logic for determining the environment in bootstrap-entries.js in this tutorial. However, you may prefer to define it based on your build pipeline instead. If this is the case for you, below you'll find code snippets you can use in place of the environment logic we'll be covering in subsequent sections:

environment.config.js - (Will be created per repository)

{
  "environment": "localhost"
}

bootstrap-entries.js

const configs = [
  `${getBasePath}environment.config.json`,
    ...
]

...

const [{ environment }, ... ] = await Promise.all(
  configs.map(config => fetch(config).then(response => response.json()))
);

...

window.__ENVIRONMENT__ = environment;

Project Setup

It's finally time to put everything we learned into action. As we cover specific files and configurations, you can reference the repository found here. Only important files and configurations will be covered.

`config/` directory

We'll set up a file called chunks.config.json inside a folder called config located in the project root. This file contains a list of local and remote entrypoints.

{
  "entrypoints": ["Host"],
  "remotes": ["RemoteFormApp"]
}

Note: This directory is where you can optionally define an environment configuration file set using your build pipeline. See the section A Quick Note on environment.config.js for more information.

environment.config.js - (Will be created per repository)

{
  "environment": "localhost"
}

`bootstrap.js`

If you are using static imports anywhere in your project, you will need to set up an asynchronous boundary in order for Module Federation to work correctly. You can do this by setting up a file called bootstrap.js and dynamically importing the main .js file of your application.

import('./app.js');

Note: For further reading on this topic, reference the following links:

Dynamically Lazy-load remote containers

Create a file called load-component.js under /src/. We'll be copy/pasting the code found on the Webpack documentation for Dynamic Remote Containers. This code allows for loading in remote containers dynamically.

const loadComponent = (scope, module) => {
  return async () => {
    await __webpack_init_sharing__('default');
    const container = window[scope];
    await container.init(__webpack_share_scopes__.default);
    const factory = await window[scope].get(module);
    const Module = factory();
    return Module;
  };
};

export default () => loadComponent;

Next, we'll be copy/pasting more code found on the Webpack documentation for Lazy Loading. We'll modify and implement this code in our bootstrap.js file below our dynamic import of app.js.

const lazyLoadDynamicRemoteApp = () => {
  const getHeader = document.getElementById('click-me');
  getHeader.onclick = () => {
    import(/* webpackChunkName: "RemoteFormApp" */ './load-component')
      .then(module => {
        const loadComponent = module.default();
        const formApp = loadComponent('FormApp', './initContactForm');
        formApp();
      })
      .catch(() => `An error occurred while loading ${module}.`);
  };
};

lazyLoadDynamicRemoteApp();

The reason why this works without a hard-coded URL is because we are dynamically assigning publicPath at runtime, getting the appropriate entrypoints, and injecting the code onto the page.

Since this includes remoteEntry.js, which in turn, loads in our remotes, we automatically have access to the remote scope FormApp and now we're able to load it successfully using only the relative path ./initContactForm located in the remote repository.

Note: If you don't want to lazy load your apps and dynamically import them normally, replace the above code with the following in bootstrap.js:

import('./load-component').then(module => {
  const loadComponent = module.default();
  const formApp = loadComponent('FormApp', './initContactForm');
  formApp();
});

Reference the `bootstrap-entries.js` file

Earlier, we set up custom code to bootstrap Webpack chunks at runtime. Now it's time to reference this in our index.html as we covered in the section Reference for Use in Repositories (reference this for more information). We'll repeat this process for all repositories.

https://cdn.jsdelivr.net/gh/waldronmatt/dynamic-module-federation-assets@1.1.1/dist/bootstrap-entries.js

<script
  preload
  src="https://unpkg.com/regenerator-runtime@0.13.1/runtime.js"
></script>
<script preload <!-- reference the bootstrap-entries.js link above -->
  src=`...`>
</script>

The bootstrap-entries.js file we're serving is a transpiled and minified version of the script to support older browsers and improve performance.

Note: regenerator-runtime is required to provide support for async/await.

Note: We can preload these scripts to improve page performance.

Note: The global mapping of hard-coded URLs we set up earlier is also located in the dynamic-module-federation-assets repository (where bootstrap-entries.js is located). The reasoning is that this file is common among all of our repositories. If we need to add, remove, or change a URL, we do it once in one location.

Webpack Configurations

Webpack Merge

The host and remote repositories use Webpack Merge to reuse common configurations and reduce the number of dependencies needed to be installed. For this tutorial I'm using my own shareable configuration found here.

Development Configuration

At minimum we'll want a development server and hot-reloading set up along with configuration defaults from our Webpack merge configuration.

We're adding a configuration to the development server header to ignore CORS. You can add optional linters and any other configurations needed. The final code for webpack.dev.js for host and remote repositories can be found below:

const commonConfig = require('./webpack.common.js');
const extendWebpackBaseConfig = require('@waldronmatt/webpack-config');
const path = require('path');
const webpack = require('webpack');

const developmentConfig = {
  devServer: {
    contentBase: path.resolve(__dirname, './dist'),
    headers: {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, PATCH, OPTIONS',
      'Access-Control-Allow-Headers':
        'X-Requested-With, content-type, Authorization',
    },
    index: 'index.html',
    port: 8000,
  },
  plugins: [new webpack.HotModuleReplacementPlugin()],
};

module.exports = extendWebpackBaseConfig(commonConfig, developmentConfig);

Production Configuration

We can leverage Webpack's splitchunks functionality for splitting up code alongside dynamically loaded remotes and local code.

Since our remote FormApp will require extra dependencies, we can tell Webpack to split up code belonging to libraries in a separate file.

cacheGroups: {
  vendor: {
    name:  `Vendors-${mainEntry}`,
    chunks:  'async',
    test: /node_modules/,
  },
},

Note: The name of the chunk is important. It must be unique to avoid namespace collisions with remotes. Using the name of the main entrypoint alongside a naming system describing the nature of the code split (vendors in our case) might be a good way to keep names unique.

Note: If you recall earlier, in order for Module Federation to work, we were required to set up an asynchronous boundary so that static imports would be supported. Now all of our code is async which means we'll also need to set chunks to be async for our configuration.

We can repeat this process for splitting up code shared between entry points. The final code for the host and remote repositories can be found below:

const commonConfig = require('./webpack.common.js');
const extendWebpackBaseConfig = require('@waldronmatt/webpack-config');
const chunks = require('./config/chunks.config.json');
const mainEntry = chunks.entrypoints[0];

const productionConfig = {
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          name: `Vendors-${mainEntry}`,
          chunks: 'async',
          test: /node_modules/,
          priority: 20,
        },
        common: {
          name: `Common-${mainEntry}`,
          minChunks: 2,
          chunks: 'async',
          priority: 10,
          reuseExistingChunk: true,
          enforce: true,
        },
      },
    },
  },
};

module.exports = extendWebpackBaseConfig(commonConfig, productionConfig);

Common Configuration

Lastly, we'll set up core configurations required for Webpack and Module Federation to run properly.

Host Module Federation Configuration

The host will contain our shared contract of dependency versions between remotes. We do this by declaring the shared property. For convenience, we're using an optional plugin called automatic-vendor-federation to make it easier to get version data and exclude libraries from the negotiation process.

const ModuleFederationConfiguration = () => {
  const AutomaticVendorFederation = require('@module-federation/automatic-vendor-federation');
  const packageJson = require('./package.json');
  const exclude = ['express', 'serverless-http'];

  return new ModuleFederationPlugin({
    shared: AutomaticVendorFederation({
      exclude,
      packageJson,
      shareFrom: ['dependencies'],
      jquery: {
        eager: true,
      },
    }),
  });
};

Remote Module Federation Configuration

The remote configuration will contain the scope name, the module exposed alongside its' relative path in the repository, and lastly, the default name of the remote entrypoint used to bootstrap remotes:

const ModuleFederationConfiguration = () => {
  return new ModuleFederationPlugin({
    name: 'FormApp',
    filename: 'remoteEntry.js',
    exposes: {
      './initContactForm': './src/form/init-contact-form',
    },
  });
};

`DynamicContainerPathPlugin`

Next we configure DynamicContainerPathPlugin to set publicPath at runtime:

const DynamicContainerPathPlugin =
  require('dynamic-container-path-webpack-plugin');
const setPublicPath =
  require('dynamic-container-path-webpack-plugin/set-path');

new  DynamicContainerPathPlugin({
    iife:  setPublicPath,
    entry:  mainEntry,
}),

Essential Configurations

The next step is to configure our entrypoints, output configurations, and remaining plugins. First, we'll set up our main entrypoint. The referenced file should be bootstrap.js, our asynchronous boundary for static imports.

target:  'web',
entry: {
  [mainEntry]: ['./src/bootstrap.js'],
},

The output configuration has a publicPath default value of /. This can be ignored because DynamicContainerPathPlugin will modify the value at runtime.

output: {
  publicPath:  '/',
  path:  path.resolve(__dirname, './dist'),
},

`runtimeChunk: single`

The Webpack merge configuration used in these repositories has runtimeChunk: single set as an optimization default so that the runtime file is shared across all generated chunks.

At the time of this writing, there is an issue with Module Federation where this setting doesn't empty out federated container runtimes; breaking the build. We override by setting runtimeChunk to false.

optimization: {
  runtimeChunk:  false,
},

`HtmlWebpackPlugin`

This plugin is used to generate the html. We don't want our js assets duplicated by HtmlWebpackPlugin since we are already dynamically injecting our entrypoints at runtime and no longer need to bootstrap them at compile time. We'll use excludeChunks to do this:

new  HtmlWebpackPlugin({
  filename:  'index.html',
  title:  `${mainEntry}`,
  description:  `${mainEntry} of Module Federation`,
  template:  'src/index.html',
  excludeChunks: [...chunks.entrypoints],
}),

Other Plugins

We're adding ProvidePlugin to define jQuery (we're using this library primarily to test out the Module Federated library negotiation process).

We're also going to add CopyPlugin to copy over the config/ directory containing our chunk mappings and WebpackAssetManifest to generate a mapping of cache-busted assets.

new webpack.ProvidePlugin({
  $:  'jquery',
  jQuery:  'jquery',
}),
new CopyPlugin({
  patterns: [{ from:  'config', to:  '' }],
}),
new WebpackAssetsManifest({}),

The entire code should look like the following:

webpack.common.js

const path = require('path');
const webpack = require('webpack');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const CopyPlugin = require('copy-webpack-plugin');
const WebpackAssetsManifest = require('webpack-assets-manifest');
const { ModuleFederationPlugin } = require('webpack').container;
const DynamicContainerPathPlugin = require('dynamic-container-path-webpack-plugin');
const setPublicPath = require('dynamic-container-path-webpack-plugin/set-path');
const chunks = require('./config/chunks.config.json');
const mainEntry = chunks.entrypoints[0];

const commonConfig = isProduction => {
  // HOST M.F. Configuration
  const ModuleFederationConfiguration = () => {
    const AutomaticVendorFederation = require('@module-federation/automatic-vendor-federation');
    const packageJson = require('./package.json');
    const exclude = ['express', 'serverless-http'];

    return new ModuleFederationPlugin({
      shared: AutomaticVendorFederation({
        exclude,
        packageJson,
        shareFrom: ['dependencies'],
        jquery: {
          eager: true,
        },
      }),
    });

    // REMOTE M.F. Configuration
    const ModuleFederationConfiguration = () => {
      return new ModuleFederationPlugin({
        name: 'FormApp',
        filename: 'remoteEntry.js',
        exposes: {
          './initContactForm': './src/form/init-contact-form',
        },
      });
    };
  };

  return {
    target: 'web',
    entry: {
      [mainEntry]: ['./src/bootstrap.js'],
    },
    output: {
      publicPath: '/',
      path: path.resolve(__dirname, './dist'),
    },
    optimization: {
      runtimeChunk: false,
    },
    plugins: [
      new webpack.ProvidePlugin({
        $: 'jquery',
        jQuery: 'jquery',
      }),
      new CopyPlugin({
        patterns: [{ from: 'config', to: '' }],
      }),
      new WebpackAssetsManifest({}),
      new HtmlWebpackPlugin({
        filename: 'index.html',
        title: `${mainEntry}`,
        description: `${mainEntry} of Module Federation`,
        template: 'src/index.html',
        excludeChunks: [...chunks.entrypoints],
      }),
      new DynamicContainerPathPlugin({
        iife: setPublicPath,
        entry: mainEntry,
      }),
    ].concat(ModuleFederationConfiguration),
  };
};

module.exports = commonConfig;

Conclusion

If you've made it this far, thank you and congratulations! You can find all of the code covered in the following repositories:

There was a lot to cover, but the end result is a solution that supports fully dynamic, multi-environment configuration.

To recap, this is what we covered in this guide:

A high level overview of Module Federation and its' advantages and disadvantages.
A summary of the problem and the desired technical outcomes.
An overview of various solutions identified and project structure.
How to mutate publicPath and bootstrap chunks dynamically.
Overview of core project files and Webpack configurations.

Lastly, we'll review the advantages using this method as well as the disadvantages so you can make an informed decision on determining if this is the right approach for you:

Advantages:

More easily support multiple testing environments without adding more complexity to your bundle configurations (hard-coded URLs)
URLs only need to be updated once in one location (map.config.js).
Environment context setting can be deferred to the build pipeline.
Despite having remote and host containers initialize at runtime, you can still leverage all of Module Federation's current features (library negotiation, etc.)
Most configuration code, including Webpack configurations, can be bundled and reused as scaffolding for other projects.
Continue to leverage advanced Webpack features alongside Module Federation including code-splitting, lazy-loading, cache-busting, webpack merge support, etc.

Disadvantages

Repositories are dependent on a single global file of URL mappings. Careful planning is required to ensure downtime is kept to a minimum.
Renaming entrypoints will require updates at the project level (chunks.config.js) and at the global level (map.config.json). Any host applications referencing remotes will need their references in chunks.config.js updated too.
Configurations covered adds a fair amount of complexity and requires a deeper level knowledge of Webpack that teams will need to familiarize themselves with.

Alternative Approaches

Alternative approaches that aim to provide similar functionality to what was described above can be found in the following repositories:

Dynamic Remote Vendor Sharing Example

Module Federation Dynamic Remotes With Runtime Environment Variables

Dynamic Remote with Vendor Sharing and Synchronous imports Example

Additional Readings

I would like to share additional references that helped solidify my understanding of Module Federation:

Module Federtation overview and setup guide

Overview of recent API changes

Detailed review of recent API changes

How static imports are hoisted in Module Federation

Dependency version negotiation/contract guide

List of API options and their descriptions

Module Federation podcast overview

Module Federation podcast slide references

Analysis of Micro Frontends in Enterprise

License

MIT

DEV Community: Matthew Waldron

Supercharge your Build Tooling

Frontend Tooling

Extendable Configurations

Versioning and Publishing

Monorepos

Conclusion

Module Federation for Enterprise (Part 2)

Before We Begin

High Level Overview

Project Structure

The NormalModuleReplacementPlugin

Code for Initializing Dynamic Remotes

Conclusion

8 Must-Have GitHub Repos for Front-end Developers

Why Write This Article?

Prerequisites

1. The Dotfiles Repository

2. The .extra Repository

3. The .github Repository

4. The Shareable Config Monorepo

5. The Mighty Template Repository

6. The Personal Portfolio Repository

7. The Resume Repository

8. The GitHub README.md Repository

Conclusion

Tutorial - A Guide to Module Federation for Enterprise

Update: 4/17/2022

Update: 9/11/2021

An Approach to Module Federation for Enterprise

Who is this Guide For?

Introduction

Advantages

Limitations

Conclusion

High Level Overview

MutateRuntimePlugin.js

Multi-Environment Architecture

Dynamic Remote Containers

Webpack Configurations

Project Setup

dynamic-container-path-webpack-plugin

Shared Configs

Host / Remote

Host

Remote

Mutating publicPath via Global Variable Assignment

Discussions on publicPath Assignment Options

High Level Overview

Tapping into PublicPathRuntimeModule

changePublicPath Method

iife and entry

Creating a Global Mapping of Endpoints

Writing a Script to Bootstrap Chunks

Initial Setup

Fetch Configurations and Assign to Global Variables

Fetch JavaScript from entrypoints and Inject on the Page

A Note on environment.config.js

Project Setup

config/ directory

bootstrap.js

Dynamically Lazy-load remote containers

Reference the bootstrap-entries.js file

Webpack Configurations

Webpack Merge

Development Configuration

Production Configuration

Common Configuration

Host Module Federation Configuration

Remote Module Federation Configuration

DynamicContainerPathPlugin

Essential Configurations

runtimeChunk: single

HtmlWebpackPlugin

Other Plugins

Conclusion

Alternative Approaches

Additional Readings

License

The `NormalModuleReplacementPlugin`

2. The `.extra` Repository

3. The `.github` Repository

8. The GitHub `README.md` Repository

Discussions on `publicPath` Assignment Options

Tapping into `PublicPathRuntimeModule`

`changePublicPath` Method

`iife` and `entry`

Fetch JavaScript from `entrypoints` and Inject on the Page

A Note on `environment.config.js`

`config/` directory

`bootstrap.js`

Reference the `bootstrap-entries.js` file

`DynamicContainerPathPlugin`

`runtimeChunk: single`

`HtmlWebpackPlugin`