Skip to content

Commit 6d75921

Browse files
manfredsteyermanfredsteyer
committed
chor: making 14.0.0 release ready
1 parent 8baf352 commit 6d75921

File tree

7 files changed

+43
-16
lines changed

7 files changed

+43
-16
lines changed

‎libs/mf-runtime/package.json

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"name": "@angular-architects/module-federation-runtime",
33
"license": "MIT",
4-
"version": "14.0.0-beta.1.12",
4+
"version": "14.0.1",
55
"peerDependencies": {
66
"@angular/common": ">=12.0.0",
77
"@angular/core": ">=12.0.0"

‎libs/mf-tools/README.md

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,8 @@ This can help to **balance the trade-off** between bundle size and isolation of
1414

1515
> **Disclaimer:** Multi-Framework and -Version Micro increase the overall complexity and call for some workarounds. This library tries to hide some of them.
1616
17+
18+
1719
## Examples
1820

1921
- [Live Example](https://red-ocean-0fe4c4610.azurestaticapps.net)
@@ -110,6 +112,27 @@ export const APP_ROUTES: Routes = [
110112
}
111113
```
112114
115+
### Important: Angular 13+
116+
117+
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):
118+
119+
```typescript
120+
export const APP_ROUTES: Routes = [
121+
[...]
122+
{
123+
path: 'angular1',
124+
component: WebComponentWrapper,
125+
data: {
126+
type: 'module',
127+
remoteEntry: 'https://your-path/remoteEntry.js',
128+
exposedModule: './web-components',
129+
elementName: 'angular1-element'
130+
} as WebComponentWrapperOptions
131+
},
132+
[...]
133+
}
134+
```
135+
113136
## Sub-Routes
114137
115138
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

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,12 @@
11
{
22
"name": "@angular-architects/module-federation-tools",
3-
"version": "14.0.0-rc.1",
3+
"version": "14.0.1",
44
"license": "MIT",
55
"peerDependencies": {
66
"@angular/common": ">=11.0.0",
77
"@angular/core": ">=11.0.0",
88
"@angular/router": ">=11.0.0",
9-
"@angular-architects/module-federation": "^14.0.0-rc.1",
9+
"@angular-architects/module-federation": "^14.0.1",
1010
"@angular/platform-browser": ">=11.0.0",
1111
"rxjs": ">= 6.0.0"
1212
},

‎libs/mf/README.md

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -33,13 +33,14 @@ Since Version 1.2, we also provide some advanced features like:
3333

3434
✅ Sharing Libs of a Monorepo
3535

36-
## What's new in Version 12.0.0-beta.x?
36+
## Which Version to use?
3737

38-
✅ Works with CLI 12.0.0-rc.1 that brings webpack 5 out of the box
38+
- Angular 12: @angular-architects/module-federation: ^12.0.0
39+
- Angular 13: @angular-architects/module-federation: ^14.0.0
3940

40-
✅ Issues with sharing libs in monorepos are resolved (always worked with multiple repos)
41+
Beginning with Angular 13, we had to add some changes to adjust to the Angular CLI. Please see the next section for this.
4142

42-
## Upgrade from Angular 12
43+
## Upgrade from Angular 12 or lower
4344

4445
Beginning with Angular 13, the CLI generates EcmaScript modules instead of script files. This affects how we work with Module Federation a bit.
4546

@@ -127,8 +128,8 @@ const routes: Routes = [
127128
path: 'flights',
128129
loadChildren: () =>
129130
loadRemoteModule({
131+
type: 'module',
130132
remoteEntry: 'http://localhost:3000/remoteEntry.js',
131-
remoteName: 'mfe1',
132133
exposedModule: './Module'
133134
})
134135
.then(m => m.FlightsModule)
@@ -146,7 +147,7 @@ For this, you could call ``loadRemoteEntry`` BEFORE bootstrapping Angular:
146147
import { loadRemoteEntry } from '@angular-architects/module-federation';
147148

148149
Promise.all([
149-
loadRemoteEntry('http://localhost:3000/remoteEntry.js', 'mfe1')
150+
loadRemoteEntry({type: 'module', remoteEntry: 'http://localhost:3000/remoteEntry.js'})
150151
])
151152
.catch(err => console.error('Error loading remote entries', err))
152153
.then(() => import('./bootstrap'))
@@ -155,7 +156,7 @@ Promise.all([
155156

156157
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.
157158

158-
Then, when loading the remote Module, just skip the ``remoteEntry`` property:
159+
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:
159160

160161
```typescript
161162
import { loadRemoteModule } from '@angular-architects/module-federation';
@@ -167,9 +168,8 @@ const routes: Routes = [
167168
path: 'flights',
168169
loadChildren: () =>
169170
loadRemoteModule({
170-
// Skipped - already loaded upfront:
171-
// remoteEntry: 'http://localhost:3000/remoteEntry.js',
172-
remoteName: 'mfe1',
171+
type: 'module',
172+
remoteEntry: 'http://localhost:3000/remoteEntry.js',
173173
exposedModule: './Module'
174174
})
175175
.then(m => m.FlightsModule)

‎libs/mf/package.json

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"name": "@angular-architects/module-federation",
3-
"version": "14.0.0-rc.1",
3+
"version": "14.0.1",
44
"license": "MIT",
55
"repository": {
66
"type": "GitHub",
@@ -17,7 +17,7 @@
1717
"schematics": "./collection.json",
1818
"builders": "./builders.json",
1919
"dependencies": {
20-
"@angular-architects/module-federation-runtime": "14.0.0-rc.1",
20+
"@angular-architects/module-federation-runtime": "14.0.1",
2121
"word-wrap": "^1.2.3",
2222
"callsite": "^1.0.0",
2323
"node-fetch": "^2.6.1",

‎migration-guide.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -128,6 +128,10 @@ To prevent issues with live reloads, you need to add a ``publicHost`` property t
128128
[...]
129129
```
130130

131+
### Deployment: Enable CORS
132+
133+
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).
134+
131135
### Advanced: Dynamic Federation with Script-based Remotes
132136

133137
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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@
1515
"skipDefaultLibCheck": true,
1616
"baseUrl": ".",
1717
"paths": {
18-
"@angular-architects/mf": ["libs/mf/src/index.ts"],
18+
"@angular-architects/module-federation": ["libs/mf/src/index.ts"],
1919
"@angular-architects/module-federation-runtime": [
2020
"libs/mf-runtime/src/index.ts"
2121
],

0 commit comments

Comments
 (0)