2

This architecture is an absolute nightmare to work with, but hopefully someone is able to give me a hand. I'm using Angular 13, and @angular-architects/module-federation 14.2.0.

I'll try to give a simplified version of the project I'm working with.

project structure is

↓project-name
  ↓dist
    >project1
    >project2
    >shell
    >shared-library
  >node_modules
  ↓projects
     >project1
     >project2
     >shell
     >shared-library

Shell and each project have this in their webpack.config:

 sharedMappings.register(
    path.join(__dirname, '../../tsconfig.json'),
    ['@shared-library']

tsconfig.json has this path setup for shared-library

"@shared-library": [
    "projects/shared-library/src/public-api.ts"
  ],

I've seen some random blogs that show the tsconfig.json path using the path to the library in the dist folder instead of public-api.ts. I've tried that, but it does nothing either.

shared-library has a structure like

>shared-library
  ↓src
    >lib
    >shared-library.module.ts
    >shared-library.service.ts
  public-api.ts

shared-library.service.ts has the @Injectable({ providedIn: 'root' }) decorator.

The components that are using shared-library.service are importing it using

import { SharedLibraryService } from '@shared-library';
constructor(private shared-library: SharedLibraryServce) {}

When I run it locally it works fine, the shared-library.service is a singleton and each MFE can share data with it.

When I deploy the project, shared-library is instantiated in the shell and each MFE, so it totally breaks the project.

I'm not really experienced with the deployment part so I'm assuming there's something I'm doing wrong.

angular.json has "baseHref"s for each project in a structure like "/projectName/apps/project1", so when I move the files to the server, I place them in a structure like

all shell files
>apps
  >project1
  >project2

I've tried placing this library in every possible place and nothing makes a difference, but I also noticed that even if I don't put the library on the server, it still exists and is still being instantiated multiple times, so I guess deploying the library is unnecessary?

There is a lot more to the code than I provided, but I don't know that this type of project can even be done in stackblitz for a more complete example. I tried to give all code that seemed relevant to the problem, but I can give more samples of my code as requested.

Destroyerist
  • 21
  • 4
  • An easy possible fix is to use providedIn: ‘platform’ instead of root. – MikeOne Jul 03 '22 at 19:10
  • I should've mentioned it but I tried that and no luck, unless I missed something. is there any change other than changing root to platform? – Destroyerist Jul 03 '22 at 21:15
  • Hard to tell. But the libs you want to have as singletons should also be in the shared array in the webpack configs (different from sharedMappings) – MikeOne Jul 03 '22 at 21:19
  • I tried putting the lib in there as well and it didn't seem to make a difference either for some reason. the lib is properly shared and a singleton locally with or without it being on the shared array, just not when it gets deployed. – Destroyerist Jul 03 '22 at 21:22
  • changing to providedIn: 'platform' seems like it would work, but the service I'm using is using an imported auth module itself, so I'm getting an error saying no provider. if I can't figure out how to get the auth module to be provided in platform as well it may work. – Destroyerist Jul 04 '22 at 20:50

0 Answers0