Wow just wow, i think of a question you answer it in the next section, and most of the things i didnt know or think of how useful they could be, this is much appreciated, thanks syntax and specifically CJ
Web build output is placed in apps/api, what happens if there are multiple web apps, will they be all placed in api package? What was the reason for this decision?
24:40 how to add custom messages (i18next) to zod validation on client/backend? Right now is just a variable with default messages for validation constraints. Is it possible to use i18next like in express/fastify/deno?
Does the IDE autocomplete speed suffer? Typescript aliases in monorepos are prone to causing performance issues. How much Memory does you setup consume to run all processes the background? Monorepos are notorious memory hungry, because each workspace has to run it's own isolated typescript LSP server and you recommend running the dev mode in watch mode that will increase your system memory usage even futher. All the examples and recommendations can work nicely on small toy projects, but have you tried measuring it on bigger ones like react or tldaw, you showed in the beginning? Why its important: many of these tools and solutions are incredibly memory hungry -> and you just flat out can't run everything at once if you do not have 64-128 gb of memory on bigger projects.
I think that's where a turborepo really shines. It caches everything after build and won't rebuild it unless it changes. You can get a pretty nice performance boost from this. I agree though, you can definitely run into memory issues if you're not careful
@@justinoneill2837 I tried Tuborepo. My system chocked on the memory requirements. I now seriosly think about upgrading my system (24 GB currently). Seems like anything less than 64 GB of ram is not enough for *simple* web dev stuff.... That a strange world we live in there we have to have 64 GB RAM to output some simple text/html.....
I really need a good explanation why is all the tooling around mono repos needed. Just put things on different folders, and define different entry points to the same application. Why something more complicated is needed ? It only makes sense a medium to big scale
@@zzej @danielo515 if you are only sharing types with one app, then it really doesn’t make sense. The tooling is necessary _mostly_ because of CI. Without tooling like Nx/Turbo you’ll build AppA and AppB everytime you push changes to Github let’s say. You only want to build the app that actually changed.
working with a mono repo is fine for a small team working one big project, but I found that eventually the packages should be moved to it's own repo and developed separately. The other main problem with mono repos is the CI/CD pipelines get super confusing. Even as a small solo developer if you build out @solo/shadcn and @solo/utilis npm packages the next time you start even a demo app you can just import from your packages and not have to bother setting up a mono repo structure.
Mono repos are very good in places where product wide changes are required. I'm able to implement security compliant tools and standards easily for our whole product in one go. We have 7 UI applications in our monorepo all sharing lots of common code and incredibly low barrier to get started. The tooling complexity in CI pipelines exists but if you understand tools like Nx or Turborepo, you can get really far with just the basic features. I have performed 6 or 7 huge migrations and refactors in the past 4 years which would have been impossible without a monorepo.
Thank you for this videos! I apreciate. I was just looking for something like this. is it possible de disable the Auto dubing ? comming on th vidéo and ear an AI generated voice disturb me.
16:35 The general feeling that I’ve gotten is that subpath imports are the preferred go forward instead of typescript path aliases, even for typescript since 5.4.
Yes, that still seems to be the case. I think the only way around it would be to generate the Zod schemas at build time. Haven't found anything for that though.
@syntaxfm yeah it's the one thing I think prisma does have over Drizzle, having that generation step allows for things like Zod schemas to be generated at build time
Yep, that's the beauty of using a Monorepo. Every project inside of apps is its own project. If you're in the root you can just write pnpm dev and it spin all of them up at the same time
It doesn't make sense to me to put eslint config as another workspace, i prefer one eslint flat config in root project and use "files" and "ignore" to apply lint to specific workspace instead It makes more sense to create typescript config workspace instead
why would you use one for a dashboard of the normal site? why wouldnt i just make a dashboard route with auth/middleware? srs question, im new. i was told about monorepos when i tried making a react native port of my nextjs project, so i could share stuff but ive just makin a protected route for admin stuff. did i do this all wrong lmao
That's fine to do, my company has it like that currently. I would prefer to have it a separate app in a monorepo though because it's leading to a ton of code sitting side by side in our components folder for example that have virtually nothing to do with each other. And when you go searching for code in the client you're getting files that are for the dashboard that you might not even realize are just for the dashboard. I think it's a better dev organization experience basically.
@@OranjeDiscoDancer ahh ok thank you, that makes sense; was worried it was a security thing. but i have deff accidentally changed the file called layout.tsx instead of layout.tsx. or actually no, i think it was layout.tsx.... god i love nextjs app router.
This is probably the best guide on monorepos on youtube. thanks!
probably one of the best channels around tech, also CJ man thanks!
A christmas miracle. This is literally what I was looking for. Thanks.
Same here hahah 🥳
I like the Spanish audio and the material that includes Hono , Thank you!
in my experience, primarily use of monorepo was making atomic changes to decoupled parts of an application that might also not be in same language
Wow just wow, i think of a question you answer it in the next section, and most of the things i didnt know or think of how useful they could be, this is much appreciated, thanks syntax and specifically CJ
Another excellent video CJ! I appreciate the insights and the details.
Lots of cool stuff in this one! Thanks CJ! Merry Christmas!
I've been doing this for a while, but you really opened my eyes to a lot of things like the pnpm task runner and parallel tasks. Thanks for this vid 🙏
Yeah that was a golden nugget! I was always reaching for the package npm-run-all. Deno also has built-in task runners
I was just looking for a in depth monorepo video, Thank You CJ
I love your content.
thanks CJ! can we get a video going over how to efficiently manage a database package using Drizzle in this monorepo setup? ie. shared schemas, etc
Its like you guys knew what I needed help figuring out! Thank you guys for all the amazing content!
Excellently explained. Nice guide
Thank you for the Christmas gift CJ
Always happy to watch your videos 💙
Awesome work! Was just looking for something like this, thanks a lot!
Is there a playlist with all the videos made by this guy? Extremely good content
Thanks! All my Syntax videos are here: ruclips.net/p/PLLnpHn493BHEF02eKUy4fdFv1RP-2q3SF
You can also check out www.youtube.com/@CodingGarden
Your template video is very amazing.. thanks CJ,
and Please make this monorepos tutorial in depth like Hono Backend or Nextjs like. Please pleaseee
Web build output is placed in apps/api, what happens if there are multiple web apps, will they be all placed in api package?
What was the reason for this decision?
24:40 how to add custom messages (i18next) to zod validation on client/backend? Right now is just a variable with default messages for validation constraints. Is it possible to use i18next like in express/fastify/deno?
Does the IDE autocomplete speed suffer? Typescript aliases in monorepos are prone to causing performance issues.
How much Memory does you setup consume to run all processes the background? Monorepos are notorious memory hungry, because each workspace has to run it's own isolated typescript LSP server and you recommend running the dev mode in watch mode that will increase your system memory usage even futher.
All the examples and recommendations can work nicely on small toy projects, but have you tried measuring it on bigger ones like react or tldaw, you showed in the beginning?
Why its important: many of these tools and solutions are incredibly memory hungry -> and you just flat out can't run everything at once if you do not have 64-128 gb of memory on bigger projects.
I think that's where a turborepo really shines. It caches everything after build and won't rebuild it unless it changes. You can get a pretty nice performance boost from this. I agree though, you can definitely run into memory issues if you're not careful
@@justinoneill2837
I tried Tuborepo. My system chocked on the memory requirements. I now seriosly think about upgrading my system (24 GB currently). Seems like anything less than 64 GB of ram is not enough for *simple* web dev stuff....
That a strange world we live in there we have to have 64 GB RAM to output some simple text/html.....
It would be interesting to see how you can combine deno js and pnpm in one monorep
This is a question I have to.. But I believe Deno replaces PNPM for this stuff.
I really need a good explanation why is all the tooling around mono repos needed. Just put things on different folders, and define different entry points to the same application. Why something more complicated is needed ? It only makes sense a medium to big scale
I know right! Like just let me share types, it shouldn’t be that difficult
@@zzej @danielo515 if you are only sharing types with one app, then it really doesn’t make sense.
The tooling is necessary _mostly_ because of CI. Without tooling like Nx/Turbo you’ll build AppA and AppB everytime you push changes to Github let’s say. You only want to build the app that actually changed.
Very informative.
what a perfect timing
nice content!
Is there any difference if I use bun instead of pnpm?
working with a mono repo is fine for a small team working one big project, but I found that eventually the packages should be moved to it's own repo and developed separately. The other main problem with mono repos is the CI/CD pipelines get super confusing. Even as a small solo developer if you build out @solo/shadcn and @solo/utilis npm packages the next time you start even a demo app you can just import from your packages and not have to bother setting up a mono repo structure.
Mono repos are very good in places where product wide changes are required. I'm able to implement security compliant tools and standards easily for our whole product in one go. We have 7 UI applications in our monorepo all sharing lots of common code and incredibly low barrier to get started. The tooling complexity in CI pipelines exists but if you understand tools like Nx or Turborepo, you can get really far with just the basic features.
I have performed 6 or 7 huge migrations and refactors in the past 4 years which would have been impossible without a monorepo.
Google used a specialized monorepo
@@StingSting844yeah I totally agree with you. It's kind of like the atomic design concept. Make a change one place and it reflects everywhere.
well explained.
Thank you for this videos! I apreciate. I was just looking for something like this. is it possible de disable the Auto dubing ? comming on th vidéo and ear an AI generated voice disturb me.
16:35 The general feeling that I’ve gotten is that subpath imports are the preferred go forward instead of typescript path aliases, even for typescript since 5.4.
I had an issue where using drizzle-zod meant my database schema ended up in my client bundle. Is that still an issue?
Yes, that still seems to be the case. I think the only way around it would be to generate the Zod schemas at build time. Haven't found anything for that though.
@syntaxfm yeah it's the one thing I think prisma does have over Drizzle, having that generation step allows for things like Zod schemas to be generated at build time
this is gold
can I change react to other framework to create this monorepo?
Yes, inside apps/* you can have as many applications as needed
Yep, that's the beauty of using a Monorepo. Every project inside of apps is its own project. If you're in the root you can just write pnpm dev and it spin all of them up at the same time
It doesn't make sense to me to put eslint config as another workspace, i prefer one eslint flat config in root project and use "files" and "ignore" to apply lint to specific workspace instead
It makes more sense to create typescript config workspace instead
Christmas came early 🙂
no turborepo?
Thanks!!!
Pista en español wow , Gracias, aunque la voz es de mujer, se agradece completamente
Jaja
i like the manual setup
why would you use one for a dashboard of the normal site? why wouldnt i just make a dashboard route with auth/middleware? srs question, im new.
i was told about monorepos when i tried making a react native port of my nextjs project, so i could share stuff but ive just makin a protected route for admin stuff. did i do this all wrong lmao
That's fine to do, my company has it like that currently. I would prefer to have it a separate app in a monorepo though because it's leading to a ton of code sitting side by side in our components folder for example that have virtually nothing to do with each other. And when you go searching for code in the client you're getting files that are for the dashboard that you might not even realize are just for the dashboard.
I think it's a better dev organization experience basically.
@@OranjeDiscoDancer ahh ok thank you, that makes sense; was worried it was a security thing. but i have deff accidentally changed the file called layout.tsx instead of layout.tsx. or actually no, i think it was layout.tsx.... god i love nextjs app router.
please make another one without drizzle, with mongodb and sst dev
Thank you for the code I starred it and forked it.