{"id":6208,"date":"2022-06-06T17:27:11","date_gmt":"2022-06-06T15:27:11","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=6208"},"modified":"2024-01-19T15:39:30","modified_gmt":"2024-01-19T14:39:30","slug":"whats-new-in-angular-architects-module-federation-14-3","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/whats-new-in-angular-architects-module-federation-14-3\/","title":{"rendered":"What’s New in our Module Federation Plugin 14.3?"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 10 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<\/a><\/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?<\/span><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    With version 14.3 of our CLI plugin @angular-architects\/module-federation<\/a>, we introduced support for Angular 14 and a new and more streamlined way of configuring Module Federation. Also, we add support for eager and pinned dependencies. This article shows the highlights. \ud83d\udcc2 Source Code<\/a><\/p>\n

    Updating to 14.3<\/h2>\n

    This library supports ng update<\/code>:<\/p>\n

    ng update @angular-architects\/module-federation<\/code><\/pre>\n
    If you update by hand (e. g. via npm install<\/code>), make sure you also install a respective version of ngx-build-plus<\/code> (version 14 for Angular 14, version 13 for Angular 13, etc.)<\/p>\n
    Streamlined Configuration<\/h2>\n
    While we are using customer-specific helper methods for quite a time, version 14.3 comes with a new official one called withModuleFederationPlugin<\/code>. It just takes the configuration data people normally adjust. The old way still works<\/strong>, but you might want to move over to the new more concise approach using the new withModuleFederationPlugin<\/code> helper function. The updated init<\/code> schematic and ng add<\/code> use this new way automatically if you set the --type<\/code> switch to host<\/code>, dynamic-host<\/code>, or remote<\/code>:<\/p>\n
    ng add @angular-architects\/module-federation --project mfe1 --port 4201 --type remote<\/code><\/pre>\n
    If you go with Nx, use npm install and the init schematic instead:<\/p>\n
     npm i @angular-architects\/module-federation -D \n ng g @angular-architects\/module-federation:init --project mfe1 --port 4201 --type remote<\/code><\/pre>\n
    This is an example for configuring a remote with the new streamlined form:<\/p>\n
     const { shareAll, withModuleFederationPlugin } = require('@angular-architects\/module-federation\/webpack');\n\n \/\/ Version 14\n module.exports = withModuleFederationPlugin({\n\n   name: 'mfe1',\n\n   exposes: {\n     '.\/Module': '.\/projects\/mfe1\/src\/app\/flights\/flights.module.ts',\n   },\n\n   shared: {\n     ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),\n   },\n\n });<\/code><\/pre>\n
    In version 13, the same looked like this:<\/p>\n
     \/\/ Version 13\n const ModuleFederationPlugin = require("webpack\/lib\/container\/ModuleFederationPlugin");\n const mf = require("@angular-architects\/module-federation\/webpack");\n const path = require("path");\n\n const share = mf.share;\n\n const sharedMappings = new mf.SharedMappings();\n sharedMappings.register(\n   path.join(__dirname, '..\/..\/tsconfig.json'),\n   ['auth-lib']  \n );\n\n module.exports = {\n   output: {\n     uniqueName: "mfe1",\n     publicPath: "auto"\n   },\n   optimization: {\n     runtimeChunk: false\n   },  \n   resolve: {\n     alias: {\n       ...sharedMappings.getAliases(),\n     }\n   },\n   experiments: {\n     outputModule: true\n   },  \n   plugins: [\n     new ModuleFederationPlugin({\n         library: { type: "module" },\n\n         \/\/ For remotes (please adjust)\n         name: "mfe1",\n         filename: "remoteEntry.js",  \/\/ 2-3K w\/ Meta Data\n         exposes: {\n             '.\/Module': '.\/projects\/mfe1\/src\/app\/flights\/flights.module.ts',\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\n           \/\/ Uncomment for sharing lib of an Angular CLI or Nx workspace\n           ...sharedMappings.getDescriptors()\n         })\n\n     }),\n     \/\/ Uncomment for sharing lib of an Angular CLI or Nx workspace\n     sharedMappings.getPlugin(),\n   ],\n };<\/code><\/pre>\n
    The passed configuration is a superset<\/strong> of the settings provided by webpack's ModuleFederationPlugin<\/code>. Also, it uses some smart defaults<\/strong>. Hence, consumers can build on their existing knowledge. These defaults are:<\/p>\n