angular-architects / module-federation-plugin

MIT License
731 stars 202 forks source link

Expose modules from buildable libraries #97

Closed smasala closed 2 years ago

smasala commented 3 years ago

One of the "tricks" we use the module federation for is to locally expose specific modules from libraries in order to render them in the shell (not angular and different application entirely). This saves us the heavy lifting of building and copying distribution files etc. This worked when we didn't use buildable libraries. Since switching over to buildable libraries in order to take advantage of incremental builds, the compilation is no longer able to find the TS files of the exposed module when building the application. Workaround is to explicitly register the module TS file in the files sections of app's tsconfig.

Obviously including the files in the compilation makes incremental builds kind of pointless. Yes, it's only for dev env. so we can remove these configs for prod... but this is also daft. Any thoughts?

exposes: {
        './SomeModule': 'libs/my-shared-lib/src/lib/some-module/some-module.module.ts',
      },
./libs/my-shared-lib/src/lib/some-module/some-module.module.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: /Users/xxxxxx/git/my-orga/libs/my-shared-lib/src/lib/some-module/some-module.module.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
    at /Users/xxxxxx/git/my-orga/node_modules/@ngtools/webpack/src/ivy/loader.js:59:26
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
manfredsteyer commented 3 years ago

Would using SharedMappings as described in [1] under Sharing Libs of a Monorepo help here?

[1] https://www.npmjs.com/package/@angular-architects/module-federation

smasala commented 3 years ago

@manfredsteyer unfortunately not. The error call-stack is just a little longer 😂

We also use this to share nested modules via the module federation with our host/shell application. This error means that other squads cannot fully take advantage of incremental builds because then need to additionally reference the exposed modules in their tsconfig.

./libs/my-shared-lib/src/lib/some-module/some-module.module.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: /Users/xxxxxx/git/my-orga/libs/my-shared-lib/src/lib/some-module/some-module.module.ts is missing from the TypeScript compilation. Please make sure it is in your tsconfig via the 'files' or 'include' property.
    at /Users/xxxxxx/git/my-orga/node_modules/@ngtools/webpack/src/ivy/loader.js:59:26
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at runNextTicks (internal/process/task_queues.js:62:3)
    at processImmediate (internal/timers.js:434:9)
mikezks commented 2 years ago

This is by design as far as I understood your question right and more a thing about TS, Angular and Nx and less about this Module Federation package.

Either you use local file access and lose the benefits of the Nx build cache or you use buildable libs which can also be a shared dep in your Mod Fed config.

Another possible way would be building stable libs that do normally not have any active changes and map the dist path to the TS config path for your serve mode. Naturally, on change you need to rebuild them.