{"id":5187,"date":"2021-07-23T20:44:12","date_gmt":"2021-07-23T18:44:12","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=5187"},"modified":"2024-01-19T15:21:14","modified_gmt":"2024-01-19T14:21:14","slug":"pitfalls-with-module-federation-and-angular","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/pitfalls-with-module-federation-and-angular\/","title":{"rendered":"Pitfalls with Module Federation and Angular"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 7 of 10 in the series “Module Federation”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. The Microfrontend Revolution: Module Federation in Webpack 5<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. The Microfrontend Revolution: Module Federation with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Dynamic Module Federation with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Building A Plugin-based Workflow Designer With Angular and Module Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Getting Out of Version-Mismatch-Hell with Module Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Using Module Federation with (Nx) Monorepos and Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Pitfalls with Module Federation and Angular<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  8. Multi-Framework and -Version Micro Frontends with Module Federation: Your 4 Steps Guide<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  9. Module Federation with Angular’s Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  10. What’s New in our Module Federation Plugin 14.3?<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    In this article, I'm going to destroy my Module Federation example! However, you don't need to worry: It's for a very good reason. The goal is to show typical pitfalls that come up when using Module Federation together with Angular. Also, this articles presents some strategies for avoiding these pitfalls. <\/p>\n

    While Module Federation is really a straight and thoroughly thought through solution, using Micro Frontends means in general to make runtime dependencies out of compile time dependencies. As a result, the compiler cannot protect you as well as you are used to. <\/p>\n

    If you want to try out the examples used here, you can fork this example<\/a>. <\/p>\n

    "No required version specified" and Secondary Entry Points<\/h2>\n

    For the first pitfall I want to talk about, let's have a look to our shell<\/code>'s webpack.config.js<\/code>. Also, let's simplify the shared<\/code> node as follows:<\/p>\n

     shared: {\n   "@angular\/core": { singleton: true, strictVersion: true },\n   "@angular\/common": { singleton: true, strictVersion: true },\n   "@angular\/router": { singleton: true, strictVersion: true },\n   "@angular\/common\/http": { singleton: true, strictVersion: true }, \n },<\/code><\/pre>\n
    As you see, we don't specify a requiredVersion<\/code> anymore. Normally this is not required because webpack Module Federation is very smart with finding out which version you use.<\/p>\n
    However, now, when compiling the shell  (ng build shell<\/code>), we get the following error:<\/p>\n
    \n
    shared module @angular\/common - Warning: No required version specified and unable to automatically determine one. Unable to find required version for "@angular\/common" in description file (C:\\Users\\Manfred\\Documents\\artikel\\ModuleFederation-Pitfalls\\example\\node_modules\\@angular\\common\\package.json). It need to be in dependencies, devDependencies or peerDependencies.<\/p>\n<\/blockquote>\n
    The reason for this is the secondary entry point @angular\/common\/http<\/code> which is a bit like an npm package within an npm package. Technically, it's just another file exposed by the npm package @angular\/common<\/code>. <\/p>\n
    Unsurprisingly, @angular\/common\/http<\/code> uses @angular\/common<\/code> and webpack recognizes this. For this reason, webpack wants to find out which version of @angular\/common<\/code> is used. For this, it looks into the npm package's package.json<\/code> (@angular\/common\/package.json<\/code>) and browses the dependencies there. However, @angular\/common<\/code> itself is not a dependency of @angular\/common<\/code> and hence, the version cannot be found.<\/p>\n
    You will have the same challenge with other packages using secondary entry points, e. g. @angular\/material<\/code>.<\/p>\n
    To avoid this situation, you can assign versions to all shared libraries by hand:<\/p>\n
     shared: {\n   "@angular\/core": { singleton: true, strictVersion: true, requiredVersion: '12.0.0' },\n   "@angular\/common": { singleton: true, strictVersion: true, requiredVersion: '12.0.0' },\n   "@angular\/router": { singleton: true, strictVersion: true, requiredVersion: '12.0.0' },\n   "@angular\/common\/http": { singleton: true, strictVersion: true, requiredVersion: '12.0.0' }, \n },<\/code><\/pre>\n
    Obviously, this is cumbersome and so we came up with another solution. Since version 12.3, @angular-architects\/module-federation<\/a> comes with an unspectacular looking helper function called shared<\/code>. If your webpack.config.js<\/code> was generated with this or a newer version, it already uses this helper function.<\/p>\n
     [...]\n\n const mf = require("@angular-architects\/module-federation\/webpack");\n [...]\n const share = mf.share;\n\n [...]\n\n shared: share({\n   "@angular\/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' },\n   "@angular\/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' },\n   "@angular\/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },\n   "@angular\/common\/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, \n   "@angular\/material\/snack-bar": { singleton: true, strictVersion: true, requiredVersion:'auto' }, \n\n })<\/code><\/pre>\n
    As you see here, the share<\/code> function wraps the object with the shared libraries. It allows to use requiredVersion: 'auto'<\/code> and converts the value auto<\/code> to the value found in your shell's (or micro frontend's) package.json<\/code>.<\/p>\n
    Unobvious Version Mismatches: Issues with Peer Dependencies<\/h2>\n
    Have you ever just ignored a peer dependency warning? Honestly, I think we all know such situations. And ignoring them is often okay-ish as we know, at runtime everything will be fine. Unfortunately, such a situation can confuses webpack Module Federation when trying to auto-detect the needed versions of peer dependencies. <\/p>\n
    To demonstrate this situation, let's install @angular\/material<\/code> and @angular\/cdk<\/code> in a version that is at least 2 versions behind our Angular version. In this case, we should get a peer dependency warnings.<\/p>\n
    In my case this is done as follows:<\/p>\n
    npm i @angular\/material@10\n npm i @angular\/cdk@10 <\/code><\/pre>\n
    Now, let's switch to the Micro Frontend's (mfe1<\/code>) FlightModule<\/code> to import the MatSnackBarModule<\/code>:<\/p>\n
     [...]\n import { MatSnackBarModule  } from '@angular\/material\/snack-bar';\n [...]\n\n @NgModule({\n   imports: [\n     [...]\n     \/\/ Add this line\n     MatSnackBarModule,\n   ],\n   declarations: [\n     [...]  \n   ]\n })\n export class FlightsModule { }<\/code><\/pre>\n
    To make use of the snack bar in the FlightsSearchComponent<\/code>, inject it into its constructor and call its open<\/code> method:<\/p>\n
     [...]\n import { MatSnackBar } from '@angular\/material\/snack-bar';\n\n @Component({\n   selector: 'app-flights-search',\n   templateUrl: '.\/flights-search.component.html'\n })\n export class FlightsSearchComponent {\n   constructor(snackBar: MatSnackBar) {\n     snackBar.open('Hallo Welt!');\n   }\n }<\/code><\/pre>\n
    Also, for this experiment, make sure the webpack.config.js<\/code> in the project mfe1<\/code> does not<\/strong> define the versions of the dependencies shared:<\/p>\n
     shared: {\n   "@angular\/core": { singleton: true, strictVersion: true },\n   "@angular\/common": { singleton: true, strictVersion: true },\n   "@angular\/router": { singleton: true, strictVersion: true },\n   "@angular\/common\/http": { singleton: true, strictVersion: true }, \n },<\/code><\/pre>\n
    Not defining these versions by hand forces Module Federation into trying to detect them automatically. However, the peer dependency conflict gives Module Federation a hard time and so it brings up the following error:  <\/p>\n
    \n
    Unsatisfied version 12.0.0 of shared singleton module @angular\/core (required ^10.0.0 || ^11.0.0-0) ; Zone:  ; Task: Promise.then ; Value: Error: Unsatisfied version 12.0.0 of shared singleton module @angular\/core (required ^10.0.0 || ^11.0.0-0)<\/p>\n<\/blockquote>\n
    While @angular\/material<\/code> and @angular\/cdk<\/code> officially need @angular\/core<\/code> 10, the rest of the application already uses @angular\/core<\/code> 12. This shows that webpack looks into the package.json<\/code> files of all the shared dependencies for determining the needed versions.<\/p>\n
    In order to resolve this, you can set the versions by hand or by using the helper function share<\/code> that uses the version found in your project's package.json<\/code>:<\/p>\n
     [...]\n\n const mf = require("@angular-architects\/module-federation\/webpack");\n [...]\n const share = mf.share;\n\n [...]\n\n shared: share({\n   "@angular\/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' },\n   "@angular\/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' },\n   "@angular\/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },\n   "@angular\/common\/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, \n   "@angular\/material\/snack-bar": { singleton: true, strictVersion: true, requiredVersion:'auto' }, \n })<\/code><\/pre>\n
    Issues with Sharing Code and Data<\/h2>\n
    In our example, the shell<\/code> and the micro frontend mfe1<\/code> share the auth-lib<\/code>. Its AuthService<\/code> stores the current user name. Hence, the shell<\/code> can set the user name and the lazy loaded mfe1<\/code> can access it:<\/p>\n
    \"Sharing<\/p>\n
    If auth-lib<\/code> was a traditional npm package, we could just register it as a shared library with module federation. However, in our case, the auth-lib<\/code> is just a library in our monorepo. And libraries in that sense are just folders with source code. <\/p>\n
    To make this folder look like a npm package, there is a path mapping for it in the tsconfig.json<\/code>:<\/p>\n
     "paths": {\n   "auth-lib": [\n     "projects\/auth-lib\/src\/public-api.ts"\n   ]\n }<\/code><\/pre>\n
    Please note that we are directly pointing to the src<\/code> folder of the auth-lib<\/code>. Nx does this by default. If you go with a traditional CLI project, you need to adjust this by hand.<\/p>\n
    Fortunately, Module Federation got us covered with such scenarios. To make configuring such cases a bit easier as well as to prevent issues with the Angular compiler, @angular-architects\/module-federation<\/code> provides a configuration property called:<\/p>\n
     module.exports = withModuleFederationPlugin({\n\n     \/\/ Shared packages:\n     shared: [...],\n\n     \/\/ Explicitly share mono-repo libs:\n     sharedMappings: ['auth-lib'],\n\n });<\/code><\/pre>\n
    \n
    Important:<\/strong> Since Version 14.3, the withModuleFederationPlugin helper automatically shares all<\/strong> mapped paths if you don't use the property sharedMappings<\/code> at all. Hence, the issue described here, will not happen.<\/p>\n<\/blockquote>\n
    Obviously, if you don't opt-in into sharing the library in one of the projects, these project will get their own copy of the auth-lib<\/code> and hence sharing the user name isn't possible anymore. <\/p>\n
    However, there is a constellation with the same underlying issue that is everything but obvious. To construct this situation, let's add another library to our monorepo:<\/p>\n
    ng g lib other-lib<\/code><\/pre>\n
    Also, make sure we have a path mapping for it pointing to its source code:<\/p>\n
     "paths": {\n   "other-lib": [\n     "projects\/other-lib\/src\/public-api.ts"\n   ],\n }<\/code><\/pre>\n
    Let's assume we also want to store the current user name in this library:<\/p>\n
     import { Injectable } from '@angular\/core';\n\n @Injectable({\n   providedIn: 'root'\n })\n export class OtherLibService {\n\n   \/\/ Add this:\n   userName: string;\n\n   constructor() { }\n\n }<\/code><\/pre>\n
    And let's also assume, the AuthLibService<\/code> delegates to this property:<\/p>\n
     import { Injectable } from '@angular\/core';\n import { OtherLibService } from 'other-lib';\n\n @Injectable({\n   providedIn: 'root'\n })\n export class AuthLibService {\n\n   private userName: string;\n\n   public get user(): string {\n     return this.userName;\n   }\n\n   public get otherUser(): string {\n     \/\/ DELEGATION!\n     return this.otherService.userName;\n   }\n\n   constructor(private otherService: OtherLibService) { }\n\n   public login(userName: string, password: string): void {\n     \/\/ Authentication for **honest** users TM. (c) Manfred Steyer\n     this.userName = userName;\n\n     \/\/ DELEGATION!\n     this.otherService.userName = userName;\n   }\n\n }<\/code><\/pre>\n
    The shell's AppComponent<\/code> is just calling the login<\/code> method:<\/p>\n
     import { Component } from '@angular\/core';\n import { AuthLibService } from 'auth-lib';\n\n @Component({\n   selector: 'app-root',\n   templateUrl: '.\/app.component.html'\n })\n export class AppComponent {\n   title = 'shell';\n\n   constructor(\n     private service: AuthLibService\n     ) {\n\n     this.service.login('Max', null);\n   }\n\n }<\/code><\/pre>\n
    However, now the Micro Frontend has three ways of getting the defined user name:<\/p>\n
     import { HttpClient } from '@angular\/common\/http';\n import {Component} from '@angular\/core';\n import { AuthLibService } from 'auth-lib';\n import { OtherLibService } from 'other-lib';\n\n @Component({\n   selector: 'app-flights-search',\n   templateUrl: '.\/flights-search.component.html'\n })\n export class FlightsSearchComponent {\n   constructor(\n     authService: AuthLibService,\n     otherService: OtherLibService) {\n\n     \/\/ Three options for getting the user name:\n     console.log('user from authService', authService.user);\n     console.log('otherUser from authService', authService.otherUser);\n     console.log('otherUser from otherService', otherService.userName);\n\n   }\n }<\/code><\/pre>\n
    At first sight, all these three options should bring up the same value. However, if we only share auth-lib<\/code> but not<\/strong> other-lib<\/code>, we get the following result:<\/p>\n
    \"Issue<\/p>\n
    As other-lib<\/code> is not shared, both, auth-lib<\/code> but also the micro frontend get their very own version of it. Hence, we have two instances of it in place here. While the first one knows the user name, the second one doesn't.<\/p>\n
    What can we learn from this? Well, it would be a good idea to also share the dependencies of our shared libraries (regardless of sharing libraries in a monorepo or traditional npm packages!).<\/p>\n
    This also holds true for secondary entry points our shared libraries belong to.<\/p>\n
    Hint:<\/em> @angular-architects\/module-federation<\/code> comes with a helper function shareAll<\/code> for sharing all dependencies defined in your project's package.json<\/code>:<\/p>\n
     shared: {\n   ...shareAll({ \n       singleton: true, \n       strictVersion: true, \n       requiredVersion: 'auto' \n   }),\n }<\/code><\/pre>\n
    This can at least lower the pain in such cases for prototyping. Also, you can make share<\/code> and shareAll<\/code> to include all secondary entry points by using the property includeSecondaries<\/code>:<\/p>\n
     shared: share({\n     "@angular\/common": { \n         singleton: true, \n         strictVersion: true,\n         requiredVersion: 'auto',\n         includeSecondaries: {\n             skip: ['@angular\/http\/testing']\n         }\n     },\n     [...]\n })<\/code><\/pre>\n
    NullInjectorError: Service expected in Parent Scope (Root Scope)<\/h2>\n
    Okay, the last section was a bit difficult. Hence, let's proceed with an easier one. Perhaps you've seen an error like this here:<\/p>\n
    ERROR Error: Uncaught (in promise): NullInjectorError: R3InjectorError(FlightsModule)[HttpClient -> HttpClient -> HttpClient -> HttpClient]: \n   NullInjectorError: No provider for HttpClient!\n NullInjectorError: R3InjectorError(FlightsModule)[HttpClient -> HttpClient -> HttpClient -> HttpClient]: \n   NullInjectorError: No provider for HttpClient!<\/code><\/pre>\n
    It seems like, the loaded Micro Frontend mfe1<\/code> cannot get hold of the HttpClient<\/code>. Perhaps it even works when running mfe1<\/code> in standalone mode.<\/p>\n
    The reason for this is very likely that we are not exposing the whole Micro Frontend via Module Federation but only selected parts, e. g. some Features Modules with Child Routes:<\/p>\n
    \"Feature<\/p>\n
    Or to put it in another way: DO NOT<\/strong> expose the Micro Frontend's AppModule<\/code>. However, if we expect the AppModule<\/code> to provide some global services like the HttpClient<\/code>, we also need to do this in the shell's AppModule<\/code>:<\/p>\n
     \/\/ Shell's AppModule\n @NgModule({\n   imports: [\n     [...]\n     \/\/ Provide global services your micro frontends expect:\n     HttpClientModule,\n   ],\n   [...]\n })\n export class AppModule { }<\/code><\/pre>\n
    Several Root Scopes<\/h2>\n
    In a very simple scenario you might try to just expose the Micro Frontend's AppModule<\/code>.<\/p>\n
    \"AppModule<\/p>\n
    As you see here, now, the shell's AppModule<\/code> uses the Micro Frontend's AppModule<\/code>. If you use the router, you will get some initial issues because you need to call RouterModule.forRoot<\/code> for each AppModule<\/code> (Root Module) on the one side while you are only allowed to call it once on the other side.<\/p>\n
    But if you just shared components or services, this might work at first sight. However, the actual issue here is that Angular creates a root scope for each root module. Hence, we have two root scopes now. This is something no one expects. <\/p>\n
    Also, this duplicates all shared services registered for the root scope, e. g. with providedIn: 'root'<\/code>. Hence, both, the shell and the Micro Frontend have their very own copy of these services and this is something, no one is expecting.<\/p>\n
    A simple but also non preferable solutions<\/strong> is to put your shared services into the platform<\/code> scope:<\/p>\n
     \/\/ Don't do this at home!\n @Injectable({\n   providedIn: 'platform'\n })\n export class AuthLibService {\n }<\/code><\/pre>\n
    However, normally, this scope is intended to be used by Angular-internal stuff. Hence, the only clean solution here is to not share your AppModule<\/code> but only lazy feature modules. By using this practice, you assure (more or less) that these feature modules work the same when loaded into the shell as when used in standalone-mode.<\/p>\n
    Different Versions of Angular<\/h2>\n
    Another, less obvious pitfall you can run into is this one here:<\/p>\n
     node_modules_angular_core___ivy_ngcc___fesm2015_core_js.js:6850 ERROR Error: Uncaught (in promise): Error: inject() must be called from an injection context\n Error: inject() must be called from an injection context\n     at pr (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.2fc3951af86e4bae0c59.js:1)\n     at gr (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.2fc3951af86e4bae0c59.js:1)\n     at Object.e.\u0275fac [as factory] (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.2fc3951af86e4bae0c59.js:1)\n     at R3Injector.hydrate (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.js:11780)\n     at R3Injector.get (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.js:11600)\n     at node_modules_angular_core___ivy_ngcc___fesm2015_core_js.js:11637\n     at Set.forEach (<anonymous>)\n     at R3Injector._resolveInjectorDefTypes (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.js:11637)\n     at new NgModuleRef$1 (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.js:25462)\n     at NgModuleFactory$1.create (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.js:25516)\n     at resolvePromise (polyfills.js:10658)\n     at resolvePromise (polyfills.js:10610)\n     at polyfills.js:10720\n     at ZoneDelegate.invokeTask (polyfills.js:10247)\n     at Object.onInvokeTask (node_modules_angular_core___ivy_ngcc___fesm2015_core_js.js:28753)\n     at ZoneDelegate.invokeTask (polyfills.js:10246)\n     at Zone.runTask (polyfills.js:10014)\n     at drainMicroTaskQueue (polyfills.js:10427)<\/code><\/pre>\n
    With inject() must be called from an injection context<\/code> Angular tells us that there are several Angular versions loaded at once.<\/p>\n
    To provoke this error, adjust your shell's webpack.config.js<\/code> as follows:<\/p>\n
    shared: share({\n   "@angular\/core": { requiredVersion: 'auto' },\n   "@angular\/common": { requiredVersion: 'auto' },\n   "@angular\/router": { requiredVersion: 'auto' },\n   "@angular\/common\/http": { requiredVersion: 'auto' }, \n })<\/code><\/pre>\n
    Please note, that these libraries are not configured to be singletons anymore. Hence, Module Federation allows loading several versions of them if there is no highest compatible version<\/a>. <\/p>\n
    Also, you have to know that the shell's package.json<\/code> points to Angular 12.0.0 without<\/em> ^ or ~, hence we exactly need this very version. <\/p>\n
    If we load a Micro Frontend that uses a different Angular version, Module Federation falls back to loading Angular twice, once the version for the shell and once the version for the Micro Frontend. You can try this out by updating the shell's app.routes.ts<\/code> as follows:<\/p>\n
     {\n   path: 'flights',\n   loadChildren: () => loadRemoteModule({\n       remoteEntry: 'https:\/\/brave-plant-03ca65b10.azurestaticapps.net\/remoteEntry.js',\n       remoteName: 'mfe1',\n       exposedModule: '.\/Module'\n     })\n     .then(m => m.AppModule) \n },<\/code><\/pre>\n
    To make exploring this a bit easier, I've provided this Micro Frontend via a Azure Static Web App found at the shown URL.<\/p>\n
    If you start your shell and load the Micro Frontend, you will see this error.<\/p>\n
    What can we learn here? Well, when it comes to your leading, stateful framework -- e. g. Angular -- it's a good idea to define it as a singleton. I've written down some details on this and on options for dealing with version mismatches<\/a> here.<\/p>\n
    If you really, really, really want to mix and match different versions of Angular, I've got you covered with this article<\/a> and this library<\/a>. However, you know what they say: Beware of your wishes.<\/p>\n
    Bonus: Multiple Bundles<\/h2>\n
    Let's finish this tour with something, that just looks like an issue but is totally fine. Perhaps you've already seen that sometimes Module Federation generated duplicate bundles with slights different names:<\/p>\n
    \"Duplicate<\/p>\n
    The reason for this duplication is that Module Federation generates a bundle per shared library per consumer<\/strong>. The consumer in this sense is the federated project (shell or Micro Frontend) or a shared library. This is done to have a fall back bundle for resolving version conflicts. In general this makes sense while in such a very specific case, it doesn't bring any advantages. <\/p>\n
    However, if everything is configured in the right way, only one of these duplicates should be loaded at runtime. As long as this is the case, you don't need to worry about duplicates. <\/p>\n
    What's next? More on Architecture!<\/h2>\n
    So far, we've seen that Module Federation is a straightforward solution for creating Micro Frontends on top of Angular. However, when dealing with it, several additional questions come in mind:<\/p>\n