Tutorial: How to set up an Nx-style monorepo workspace with the Angular CLI

What do you think about an Nx-style monorepo workspace? Did you realize that it’s possible to do with the Angular CLI?

2 Likes

Just curious on what the reason was for using RouterModule.forRoot in the feature-shells?
In your setup, is it correct to say that each application can only have one feature shell then?
I found it slightly odd that the AppModule doesn’t load the RouterModule for the <router-outlet> directive in app component but it is required for the spec. And that is i guess, because it loads it from the feature shell modules…

1 Like

Hi Cheong,

Did you read this article?

Carefully compare the examples, both visuals and implementation. With the feature shell library pattern, we have either one application per domain or multiple platforms sharing the same feature shell library. An example of this is Slack. It more or less has the same feature set on desktop, web, and mobile.

In this case, it was a requirement as per the book. The applications use adaptive layout and header sniffing to serve multiple applications from the same URL.

Shell libraries and composite shell libraries are a different story.

1 Like

Hi Lars,

Thanks for that reference. I hadn’t read that article and just finished it.
Didn’t know that there were actually different shell library patterns (from nrwl, manifred and the composite shell library alternative)

Learnt something from your article that will make me think more into how I solution my applications in future. So thanks!

Will look more into this as well…

Looking forward to your part 5.

Cheers,
Cheong

1 Like

I’m glad I could point you towards that article, Cheong. @nacho_vazquez and I put a lot of work into it. In combination with the feature shell library examples in this tutorial series, you should get a good idea about how to orchestrate your applications and domains.

Part 5, the final one, will be published this Saturday. I’m glad that you’re able to keep up with 2 parts per week :slightly_smiling_face: Was it an okay interval used to publish the parts in?

1 Like

Hi. I’m not sure why there is a need for so many individual library projects. They’re not published, and are imported directly e.g. via tsconfig.json paths that map to the index.ts which exports the component/utils module

Would it not make sense to have a single shared library project, with a single module, that exports many components/utils. Or a library with many modules, but without the duplication of config files (karma.conf, tsconfig, tslint etc)

1 Like

Hi @Brian, welcome to the inDepth Community!

This architectural structure is meant for large and complex projects. It’s meant to scale and make it easier for multiple teams to work on the same codebase.

With granular projects, we can test or lint each project individually so that we don’t have to lint or test the whole codebase locally.

When using Nx, we even get the option to run affected builds, tests and linting, meaning we compare the current branch to another branch/commit and run commands for the projects which has code changes and every project that depends on it. Very useful way to decrease the number of tests, builds and linting to run.

Nx also has the option to do incremental builds where each or some libraries have architect build targets as well. Combined with Nx caching, this makes us able to reuse output bundles so that we will have to compile less code to build an application or a package library.

This is a tool for the right job. If we’re building a small project, we probably don’t need this. Even though I have to say that the more I use it, the more I prefer it.

Regarding large libraries exposing many declarables and services, that’s a different discussion :slightly_smiling_face:

Hi thanks a lot. Its great to find a community to discuss Angular and JS at an detailed level.

I’m a bit confused here😊 In your article you’re not using Nx, so I’m guessing those features (affected build, Nx caching etc) aren’t available there. Are we talking about the same example codebase? https://github.com/LayZeeDK/ngx-nrwl-airlines-workspace

I’ve worked on large projects with shared libraries, and app/library structures, but the libraries/modules wouldn’t be created for each element e.g Button library https://github.com/LayZeeDK/ngx-nrwl-airlines-workspace/blob/master/libs/shared/ui-buttons/src/lib/confirm-button/confirm-button.module.ts. There would usually be a shared components library, with a single module that exports the individual components. Maybe there’s an advantage to it I’m not seeing :thinking:

1 Like

You’re right, this repository is not using Nx. As mentioned in Part 5, Nx adds more capabilities than Angular CLI.

Regarding the buttons UI library, it is just a simple example. It could have multiple buttons. Buttons is probably a poor name. Maybe a better library could be ui-atoms exposing atoms in the perspective of Atomic Design. Buttons, textboxes, dropdowns, serach boxes, and so on.