chor: making 14.0.0 release ready

libs/mf-runtime/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@angular-architects/module-federation-runtime",
   "license": "MIT",
-  "version": "14.0.0-beta.1.12",
+  "version": "14.0.1",
   "peerDependencies": {
     "@angular/common": ">=12.0.0",
     "@angular/core": ">=12.0.0"

libs/mf-tools/README.md

@@ -14,6 +14,8 @@ This can help to **balance the trade-off** between bundle size and isolation of
 
 > **Disclaimer:** Multi-Framework and -Version Micro increase the overall complexity and call for some workarounds. This library tries to hide some of them.
 
+
+
 ## Examples
 
 - [Live Example](https://red-ocean-0fe4c4610.azurestaticapps.net)
@@ -110,6 +112,27 @@ export const APP_ROUTES: Routes = [
 }
 ```
 
+### Important: Angular 13+
+
+Beginning with Angular 13, the CLI is emitting EcmaScript modules. Hence, we need to adjust the usage of the WebComponentWrapper when loading a remote that has been created with the CLI 13 or higher. For this, set ``type`` to ``remote`` and skip the ``remoteName`` property (for Modules, we don't need a remoteName):
+
+```typescript
+export const APP_ROUTES: Routes = [
+    [...]
+    {
+        path: 'angular1',
+        component: WebComponentWrapper,
+        data: {
+          type: 'module',
+          remoteEntry: 'https://your-path/remoteEntry.js',
+          exposedModule: './web-components',
+          elementName: 'angular1-element'
+        } as WebComponentWrapperOptions
+    },
+    [...]
+}
+```
+
 ## Sub-Routes
 
 If a web component has it's own router, you can use our UrlMatchers ``startsWith`` and ``endsWith`` to define, which part of the URL is intended for the shell and for the micro frontend:

libs/mf-tools/package.json

@@ -1,12 +1,12 @@
 {
   "name": "@angular-architects/module-federation-tools",
-  "version": "14.0.0-rc.1",
+  "version": "14.0.1",
   "license": "MIT",
   "peerDependencies": {
     "@angular/common": ">=11.0.0",
     "@angular/core": ">=11.0.0",
     "@angular/router": ">=11.0.0",
-    "@angular-architects/module-federation": "^14.0.0-rc.1",
+    "@angular-architects/module-federation": "^14.0.1",
     "@angular/platform-browser": ">=11.0.0",
     "rxjs": ">= 6.0.0"
   },

libs/mf/README.md

@@ -33,13 +33,14 @@ Since Version 1.2, we also provide some advanced features like:
 
 ✅ Sharing Libs of a Monorepo
 
-## What's new in Version 12.0.0-beta.x?
+## Which Version to use?
 
-✅ Works with CLI 12.0.0-rc.1 that brings webpack 5 out of the box
+- Angular 12: @angular-architects/module-federation: ^12.0.0
+- Angular 13: @angular-architects/module-federation: ^14.0.0
 
-✅ Issues with sharing libs in monorepos are resolved (always worked with multiple repos)
+Beginning with Angular 13, we had to add some changes to adjust to the Angular CLI. Please see the next section for this.
 
-## Upgrade from Angular 12
+## Upgrade from Angular 12 or lower
 
 Beginning with Angular 13, the CLI generates EcmaScript modules instead of script files. This affects how we work with Module Federation a bit.
 
@@ -127,8 +128,8 @@ const routes: Routes = [
         path: 'flights',
         loadChildren: () =>
             loadRemoteModule({
+                type: 'module',
                 remoteEntry: 'http://localhost:3000/remoteEntry.js',
-                remoteName: 'mfe1',
                 exposedModule: './Module'
             })
             .then(m => m.FlightsModule)
@@ -146,7 +147,7 @@ For this, you could call ``loadRemoteEntry`` BEFORE bootstrapping Angular:
 import { loadRemoteEntry } from '@angular-architects/module-federation';
 
 Promise.all([
-    loadRemoteEntry('http://localhost:3000/remoteEntry.js', 'mfe1')
+    loadRemoteEntry({type: 'module', remoteEntry: 'http://localhost:3000/remoteEntry.js'})
 ])
 .catch(err => console.error('Error loading remote entries', err))
 .then(() => import('./bootstrap'))
@@ -155,7 +156,7 @@ Promise.all([
 
 The ``bootstrap.ts`` file contains the source code normally found in ``main.ts`` and hence, it calls ``platform.bootstrapModule(AppModule)``. You really need this combination of an upfront file calling loadRemoteEntry and a dynamic import loading another file bootstrapping Angular because Angular itself is already a shared library respected during the version negotiation.
 
-Then, when loading the remote Module, just skip the ``remoteEntry`` property:
+Then, when loading the remote Module, you set to mention the ``remoteEntry`` property anyway, as it also acts as an internal identifier for the remote:
 
 ```typescript
 import { loadRemoteModule } from '@angular-architects/module-federation';
@@ -167,9 +168,8 @@ const routes: Routes = [
         path: 'flights',
         loadChildren: () =>
             loadRemoteModule({
-                // Skipped - already loaded upfront:
-                // remoteEntry: 'http://localhost:3000/remoteEntry.js',
-                remoteName: 'mfe1',
+                type: 'module',
+                remoteEntry: 'http://localhost:3000/remoteEntry.js',
                 exposedModule: './Module'
             })
             .then(m => m.FlightsModule)

libs/mf/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@angular-architects/module-federation",
-  "version": "14.0.0-rc.1",
+  "version": "14.0.1",
   "license": "MIT",
   "repository": {
     "type": "GitHub",
@@ -17,7 +17,7 @@
   "schematics": "./collection.json",
   "builders": "./builders.json",
   "dependencies": {
-    "@angular-architects/module-federation-runtime": "14.0.0-rc.1",
+    "@angular-architects/module-federation-runtime": "14.0.1",
     "word-wrap": "^1.2.3",
     "callsite": "^1.0.0",
     "node-fetch": "^2.6.1",

migration-guide.md

@@ -128,6 +128,10 @@ To prevent issues with live reloads, you need to add a ``publicHost`` property t
 [...]
 ```
 
+### Deployment: Enable CORS
+
+As remotes are now loaded as EcmaScript modules, the same origin policy is in place. Hence, if your micro frontends and the shell are deployed to different origins, you need to enable CORS. The same holds true if you run your application after building it with a command line web server like ``serve`` (``serve``, e. g., has a ``--cors`` options). 
+
 ### Advanced: Dynamic Federation with Script-based Remotes
 
 If you also want to load (existing) script-based remotes into your shell, e. g. remotes built with Angular 12 used for a [Multi-Version/Multi-Framework setup](https://www.npmjs.com/package/@angular-architects/module-federation-tools), you can pass ``type: 'script'`` to both, ``loadRemoteModule`` and ``loadRemoteEntry``. In this case, you also need to pass a ``remoteName``.

tsconfig.base.json

@@ -15,7 +15,7 @@
     "skipDefaultLibCheck": true,
     "baseUrl": ".",
     "paths": {
-      "@angular-architects/mf": ["libs/mf/src/index.ts"],
+      "@angular-architects/module-federation": ["libs/mf/src/index.ts"],
       "@angular-architects/module-federation-runtime": [
         "libs/mf-runtime/src/index.ts"
       ],