Closed smasala closed 2 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
@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)
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.
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'stsconfig
.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?