I followed a similar approach to the Spotify project, and also followed the nx enterprise implementation using their enterprise book. One thing I struggle with is feeling like there are too many libraries. Sometimes you feel like its a lib per component or service. Sometimes I think maybe I should turn my 10 data access rest libs into a single data access rest lib; in terms of bundle size, shouldn’t tree shaking ensure only the services used are included in the bundle? For example you have two shared ui libs, but a single shared utils lib. You could have had a lib per utils file if you wanted. The balance can be tricky. Currently I am still creating a lib per rest integration, but I am uncertain from time to time.
I’m enjoying your videos, especially this one showing how to better manage personal projects. Just a suggestion to double up the zoom / font size in the VS Code screen recordings please 🙏🏻👍🏻
Hey, just one note here isn't the structure of every single component as a library a little bit overkill - meaning there are too many files with each component. Would be better to have for example /shared/ui as a library and then inside /shared/ui/src/libs/button - component? so each component will be kinda flat folder within UI library?
Hi Joshua, It seems a pain point when working with nx is deployment. For example, deploying to heroku using the standard git approach, but also dockerizing apps in nx and deploying with containers (be it Heroku or Digital Ocean, or whichever). I would personally really like a video where you explain how you do it yourself
For Netlify rather than using their auto deployment I prefer to write a deploy target in Nx and use that to deploy manually with the Netlify CLI. That way I can easily create whatever sort of build/deploy process I need in Nx, and then the resulting build is sent directly to Netlify. All I need to do for a deploy is run "nx deploy (whatever app)"
Hi Josh, what would be your approach to share global styles across your monorepo? (I mean the global styles of Ionic or Angular Material) Traditionally they would be included directly in the app itself (via direct import in the `global.scss` file or in the `angular.json assets array`). The problem is that these styles will --most likely-- be needed in some feature libs as well, so what to do then? :/
If I'm understanding correctly then this shouldn't be a problem - for example, in this project I just set up tailwind by modifying the styles.css in the app itself, then I can just use tailwind classes in my feature libraries because they will be pulled into the app where Tailwind is available. Then if you wanted to use those in some other app you would just need to make sure to include the Tailwind (or whatever else) styles in that app too.
@@JoshuaMorony Absolutely. But, what would happen then with Storybook + Libs, will they render correctly? Edit: I forgot to mention... I've been following you for a long time :) I've learned a lot from you!
@@guzmanoj I'm not sure about Storybook I haven't tried it yet but I would think that you would just need to configure the styles with Storybook in some way and then components from the library would work properly - not sure though!
This is a good question. We have a separate shared/ui library that acts as our design system. Originally, we had 3-4 separate apps with their own stylesheets, meaning that the global style "context" a component would have would depend on what app consumed the reusable component. The idea of reusable components is that they're deterministic so this becomes a nightmare pretty quickly. Ideally, we'd remove all global CSS and rely on style encapsulation instead. However, many of our UI components depended on this global style implicitly. Also, libraries like tailwind are designed to be globally imported. Our solution was just to create a single "global.scss" file that we imported into all of our apps and storybook instances. This allowed us to reuse components across the workspace without running into CSS bugs all over the place. We keep this file as small as possible. Any CSS that is specific to a component can be imported into the component's CSS instead.
I created a babel lib called style in libs/shared/ui I have a folder called @public which contains all the public sass files others can import. This folder can be added as a sass pre processor folder in angular.json file of apps, this allows styles.scss to import any public scss file from my lib. In my @public folder I have a private folder with scss partials. My public folder has common styles, themes, colours, etc
Hi Josh, I have been following your Nx series diligently and also working on my own Nx project for around 3 weeks now. I am using a similar folder structure for my project like what you have shown here. However one question I have that I couldn't really find an answer is why does Nx recommend we keep our app folder slim and place our unique app feature modules in lib instead of in the actual app folder even though they most probably won't be reusable?
Great question! I'm not sure how well this lines up with the official stance, but here's my take on that. The ability to share is just one benefit of the libraries, it would still be beneficial to build your non-shared code into libraries for the following reasons: - Just from an organisation perspective having everything co-located and following the same structure - It would be easier to move the library if you later decide to share it - It allows you to create buildable libraries/utilise incremental builds (i.e. utilise caching to execute builds faster) - It allows you to better utilise the affected commands/dependency graph (i.e. only run tests for code affected by this change) I might throw this one over to Twitter though in case I've gotten anything wrong here or missed anything!
Thank you Josh, these videos could not be more perfectly timed. I've just begun to need Nx's functionality for multiple projects I'm working on, and these videos are awesome. Question: Do you find the multiple-nested folder structure to be burdensome? It's a little intimidating for me coming from a single angular app where I was two clicks away from finding a components' files. With Nx I'm now having to drill down 4 and 5 folders deep to get to my components. Or maybe you just get used to it after a while?
This is probably the one thing that irks me a bit, I still think it is worth it, but it can be a pain. I generally use my keyboard to navigate through the explorer and yes I have gotten pretty use to popping open all the folders, but if I find myself using Finder and manually clicking into folders it is a bit annoying.
Thank you Joshua for this really informative video! What are your thoughts on using Nx for full-stack apps (e.g. with Angular and Nest)? I found it quite frustrating and tedious to run it with Docker due to shared npm packages and package files.
This is, theoretically, an ideal situation for Nx - however I haven't actually tried that scenario myself so I can't really speak to the pain points you might run into. You might find this repo from one of the Nrwl engineers useful - it's an Nx repo with Angular and Nest and uses docker: github.com/nartc/nx-mess
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076
This channel is a gem. Thank you Josh.
Great video. Very useful and very well explained for those we are new to the Nx world.🤩
I followed a similar approach to the Spotify project, and also followed the nx enterprise implementation using their enterprise book.
One thing I struggle with is feeling like there are too many libraries. Sometimes you feel like its a lib per component or service.
Sometimes I think maybe I should turn my 10 data access rest libs into a single data access rest lib; in terms of bundle size, shouldn’t tree shaking ensure only the services used are included in the bundle?
For example you have two shared ui libs, but a single shared utils lib.
You could have had a lib per utils file if you wanted.
The balance can be tricky.
Currently I am still creating a lib per rest integration, but I am uncertain from time to time.
Thank you ... this is very helpful seeing some architecture and folder structure in a real Nx workspace!
Joined the mailing list - I totally agree with your development philosophy.
I’m enjoying your videos, especially this one showing how to better manage personal projects. Just a suggestion to double up the zoom / font size in the VS Code screen recordings please 🙏🏻👍🏻
Hey, just one note here isn't the structure of every single component as a library a little bit overkill - meaning there are too many files with each component. Would be better to have for example /shared/ui as a library and then inside /shared/ui/src/libs/button - component? so each component will be kinda flat folder within UI library?
Awesome video! Thank you.
that "readFile" pipe is looking so good
thank you! josh, for lessons
Hi Joshua, It seems a pain point when working with nx is deployment. For example, deploying to heroku using the standard git approach, but also dockerizing apps in nx and deploying with containers (be it Heroku or Digital Ocean, or whichever). I would personally really like a video where you explain how you do it yourself
For Netlify rather than using their auto deployment I prefer to write a deploy target in Nx and use that to deploy manually with the Netlify CLI. That way I can easily create whatever sort of build/deploy process I need in Nx, and then the resulting build is sent directly to Netlify. All I need to do for a deploy is run "nx deploy (whatever app)"
Thanks @@JoshuaMorony ! what about if you have a node backend (rest API with nestjs, for example)
Hi Josh, what would be your approach to share global styles across your monorepo? (I mean the global styles of Ionic or Angular Material)
Traditionally they would be included directly in the app itself (via direct import in the `global.scss` file or in the `angular.json assets array`). The problem is that these styles will --most likely-- be needed in some feature libs as well, so what to do then? :/
If I'm understanding correctly then this shouldn't be a problem - for example, in this project I just set up tailwind by modifying the styles.css in the app itself, then I can just use tailwind classes in my feature libraries because they will be pulled into the app where Tailwind is available. Then if you wanted to use those in some other app you would just need to make sure to include the Tailwind (or whatever else) styles in that app too.
@@JoshuaMorony Absolutely. But, what would happen then with Storybook + Libs, will they render correctly?
Edit: I forgot to mention... I've been following you for a long time :)
I've learned a lot from you!
@@guzmanoj I'm not sure about Storybook I haven't tried it yet but I would think that you would just need to configure the styles with Storybook in some way and then components from the library would work properly - not sure though!
This is a good question.
We have a separate shared/ui library that acts as our design system.
Originally, we had 3-4 separate apps with their own stylesheets, meaning that the global style "context" a component would have would depend on what app consumed the reusable component.
The idea of reusable components is that they're deterministic so this becomes a nightmare pretty quickly.
Ideally, we'd remove all global CSS and rely on style encapsulation instead. However, many of our UI components depended on this global style implicitly. Also, libraries like tailwind are designed to be globally imported.
Our solution was just to create a single "global.scss" file that we imported into all of our apps and storybook instances. This allowed us to reuse components across the workspace without running into CSS bugs all over the place. We keep this file as small as possible. Any CSS that is specific to a component can be imported into the component's CSS instead.
I created a babel lib called style in libs/shared/ui
I have a folder called @public which contains all the public sass files others can import.
This folder can be added as a sass pre processor folder in angular.json file of apps, this allows styles.scss to import any public scss file from my lib.
In my @public folder I have a private folder with scss partials.
My public folder has common styles, themes, colours, etc
Very interesting topic!
Hi Josh, I have been following your Nx series diligently and also working on my own Nx project for around 3 weeks now. I am using a similar folder structure for my project like what you have shown here. However one question I have that I couldn't really find an answer is why does Nx recommend we keep our app folder slim and place our unique app feature modules in lib instead of in the actual app folder even though they most probably won't be reusable?
Great question! I'm not sure how well this lines up with the official stance, but here's my take on that. The ability to share is just one benefit of the libraries, it would still be beneficial to build your non-shared code into libraries for the following reasons:
- Just from an organisation perspective having everything co-located and following the same structure
- It would be easier to move the library if you later decide to share it
- It allows you to create buildable libraries/utilise incremental builds (i.e. utilise caching to execute builds faster)
- It allows you to better utilise the affected commands/dependency graph (i.e. only run tests for code affected by this change)
I might throw this one over to Twitter though in case I've gotten anything wrong here or missed anything!
Here's the response from Isaac from the Nrwl team, great stuff in here: nx.dev/structure/creating-libraries
In a large organisation you may want to embed one app inside another.
Mind blowing
How can I share a css or scss file from a lib to a NEXTjs app?
Thank you Josh, these videos could not be more perfectly timed. I've just begun to need Nx's functionality for multiple projects I'm working on, and these videos are awesome. Question: Do you find the multiple-nested folder structure to be burdensome? It's a little intimidating for me coming from a single angular app where I was two clicks away from finding a components' files. With Nx I'm now having to drill down 4 and 5 folders deep to get to my components. Or maybe you just get used to it after a while?
This is probably the one thing that irks me a bit, I still think it is worth it, but it can be a pain. I generally use my keyboard to navigate through the explorer and yes I have gotten pretty use to popping open all the folders, but if I find myself using Finder and manually clicking into folders it is a bit annoying.
Thank you Joshua for this really informative video! What are your thoughts on using Nx for full-stack apps (e.g. with Angular and Nest)? I found it quite frustrating and tedious to run it with Docker due to shared npm packages and package files.
This is, theoretically, an ideal situation for Nx - however I haven't actually tried that scenario myself so I can't really speak to the pain points you might run into. You might find this repo from one of the Nrwl engineers useful - it's an Nx repo with Angular and Nest and uses docker: github.com/nartc/nx-mess
@@JoshuaMorony Thank you for your time and the answer! Unfortunately only DB is dockerized, and the backend app is run locally.