Big buildable libraries or small?

[B1Z1]

Hi, in our company we started to move our Angular project to Nx. At this moment we have 200 libraries and 300+ to move into libraries :D. We started to make every our library buildable, but lately, I found in your documentation this article:

https://nx.dev/module-federation/faster-builds#using-buildable-libs

We don't recommend making all libraries in your workspace buildable--it will make some things faster but many other things slower. But in some scenarios making a few large libraries at the bottom of your graph buildable can speed up your CI.

Now I always think about it, because I don't know when I need to create a buildable library or a simple one. For example we have a folder UI with 100+ modules, what do I need to do?

1. Create 100+ libraries/buildable libraries
2. Create 1 big library which will export all modules in one index.ts

The first solution is great because we can lint/test/build them separately, the second solution will build them all. But the second solution will be good for tags, I don't need to add to all my 100+ libs new tags in project.json. I just can add it to only one. Also, I don't need to have .eslint, tsconfig.json, and other configurable files in every library, I will just have only one.

Do you guys have any ideas or real examples of how you solve it in your real projects?

[JamesMaroney]

We are facing the very same question. I see there hasn't been any activity on your question, but I'm interested to know if you have learned anything in the meantime you can share that makes you choose one approach over the other?

[B1Z1]

We tried to introduce to us NxCloud and we called NxCloud support/developer two weeks ago. During the call, we asked about the same question, and as I understand, better if you will have more buildable libraries. Because it's great to work with DTE and DC. At this moment we move all modules to separate buildable libraries, but if it will a bad idea, we will just remove all files which mark them as buildable

[lppedd]

@B1Z1 @JamesMaroney another aspect I just discovered is Angular + ESBuild with non-buildable libraries doesn't perform dead code elimination correctly. Whatever is exported via the library's index.ts is packaged with every application.

[MattTreichelYeah]

The most annoying part to me seems to be that buildable libraries can't import non-buildable libraries. It's a roadblock to organization to try importing something from a non-buildable library and just be blocked without clear direction on what to then do - it seems like it would just be easier to make everything buildable so everything can import from wherever it needs to. Would be nice if the docs went into the details of what "make some things faster but many other things slower" means because it's difficult to judge how important that is in relation to resolving organizational roadblocks... 🤔

If we shouldn't make everything buildable what's the criteria to choosing what shouldn't be to avoid running into issues down the line where simple packages can't import each other?

[jorgeramirezamora]

Same here. We decided to go with all libraries being buildable with Vite and applications bundling with Webpack + SWC. Still having issues with one specific big application tough... I am particularly looking forward to move applications to Rspack instead of Webpack to reduce the impact of building in the memory of containers.