What cannot be overlooked is how you provide types from your libraries to apps. If you do it as an npm package would do, via .d.ts files, you have to always rebuild the library with tsc after any modification, for the changes to be picked up by other parts of the monorepo. If you decide to point to .ts source code, you are able to skip this step, at the cost of tsc analysing your library source code even when type-checking the app, additionally imposing the same „strictness” between the compiler options (the app cannot be stricter than the library it uses).
also pointing to ts code has the downside that all code must be directly under the package root. If you were to add a _src_ folder, you'd have to type that out as well into the import path.
This is where we landed at my company. We were using nx, but I found it to be too much of a blackbox and config heavy for our use case. We landed on a top level dir of libs/ with a single tsconfig.json file that is the most strict (so that it can be pulled in by our apps/ code). It does give tsc more work to do, but it's not that bad.
Same here, we also considered using nx to combine a react native and next.js app into a monorepo. I decided to keep it super simple and use pnpm and instead of each package having a build step just add to the tsconfig includes for each app. Works really nice and we don’t publish any of our packages anywhere, they’re just shared between those apps.
Super great and to the point. It would be cool if you did a series incrementally adding only the most beneficial packages for a project to have. I believe that would be very informative
Hi, great video. This is the exact setup I implmented for our current project at work several months ago. It would be great to see some more details on the Turborepo. The documantation is good but the setup is not trivial
There is the big war on turbo vs nx.. I personally like `nx` but I am not against turbo, I have just not seen any clear reason of why I would switch, so I just stick with what I know. Though, I do like that we have 6 completely independant apps that interlink externally from, so it's nice to use the `nx` tagging system to say `serve the tag:code-name` apps, or `serve the tag:legacy`
It may depends on the FW we’re using. For instance, with Angular, nx is perfect as it comes with a lot of tools. For Vue, it’s a tad more of a struggle. While with Turbo, it’s pretty easy. (From what I’ve experimented, at least)
What I've come to find has trouble scaling is the "internal" packages you'd build continually with --watch. Monorepo really encourages you to put whatever you can in a separate package and having to build all of these each time you change anything becomes really cumbersome as you scale up. Not to mention stuff like fast-reload, which does become a bit harder to set up. I've started going down the rabbit hole of exporting the main TS file directly in "internal" packages, but that comes with its own set of issues. To be fair I don't have any answers here. It feels like this area is still not well thought-out.
bun could technically replace all of those deps - bun works in monorepo setup, is fast & doesn't require transpiling from TS to JS (hence no need for turbo) and supports TS out of the box.
thanks for the video... do you have one where you show how to configure prism with a turborepo ? if not, would you be willing to make a practical video? please?
We are using nx in our company (without DTE) and we are very happy with it. Moreover we pay 0 💵. (I am the author of nx-remotecache-gcp) so we store the cache in Google Buckets.
We used NX for awhile at my company and ultimately migrated away from it about 18 months ago. The situation may be somewhat better now, but our biggest pain points were: 1. VERY config heavy, with poorly documented options in the JSON files. There was a lot that you could do, but we wound up having to review the actual NX source code because some features weren't even mentioned in the docs. 2. Commingled dependencies. All projects share a SINGLE package.json in the project root. If project A depends on React@16 but project B needs React@18, you're SOL. There's no way to (sensibly) migrate one project at a time. This also has weird implications for Intellisense as you might get hinting suggestions for React packages when you're working on the API.
How are PRs managed in large monorepos? For example, I get the idea of using a monorepo for building a design system but when we add something like `/apps` to it; Are we adding "real" apps to the monorepo as well? and if this is the case, if you have 8-10 apps using your design system, how are PRs managed?
the biggest pain in a monorepo setup is the watch mode. In the given example, if you run a certain package in watch mode, the watcher will only listen to files within that package. It won't re-build on monorepo dependencies change. I wonder what's your typical solution to this problem. A root-level tsconfig with specified paths is kind of a solution, but it requires paths to be manually maintained, which doesn't play nicely with the philosophy of a monorepo where packages are supposed to be self-contained.
This can’t be happening right now. I spent 5 days fighting my tsconfig to build my honojs api and I gave up and used eabuild 6 hours before this video dropped 😂. Awesome video as always!
This looks very easy to use, and I would be tempted to try it. However, I've gotten so used to Deno (and have actually crafted a small monorepo setup that works for me), that I kinda don't wanna go back to plain Node.js? Is there a way to combine Deno and Monorepo?
My favorite kind of monorepo is one that doesn't even have a package.json in the root of the repository. The folder structure is as follows: apps/ app1 ... appN/ packages/ package1 ... packageN/ Each app and package is essentially "isolated" with their own package.json files, and the packages are all published and versioned to a private registry.
It's funny... watching this inspired me to give one of my personal projects a tidy up... but I ended up using a completely different tool kit to yours... ... "completely different"? ... ... well not quite.... ... it's got to have typescript right? ... ... right!
@@mattpocockuk it wasn't a monorepo or anything: yarn, vitest, tsx, tsc, 11ty-3.0-alpha, eslint, stylelint, prettier... not exactly "minimal" either ;)
How do you handle external deps? Eg you have multiple libs all using a 3rd party. Do you use the root package.json or per library imports and then have to deal with the version syncing explicitly per package. We currently use the root approach as easier to maintain but I can’t help but think it is killing build times as everything now has everything in its package.json. E.g. Monaco editor is huge and now all our projects have it in their packages due to it being in the root one. There is very little guidance on this in the docs…..
Why would having a package in your node modules affect your build? If it's not requested by that app it won't be part of the code parsed for the build. The only way it would slightly slow things down is the install step. That said, I do recommend that all runtime dependencies are installed in the closest package.json. Implicit dependencies suck.
I am curious why you are choosing to go with pnpm? You don't really go into the why of that one. npm recently got caching similar to pnpm, so I am not sure what other reasons there are to use it. testing locally, I do save a fraction of the time using pnpm, but I am just not sure it is worth it
Well especially in a monorepo where packages are published I really enjoy the `workspace:` protocol, as it reduces churn. NPM plain doesn't support that.
With this setup, does each project run type checks on all dependencies as well as itself? How do you run type checks in this setup without doing a lot of duplicative work?
Hmm if I were to build something like a component library or utils library where the monorepo is just for bundling everything in one place would it make sense to use such tools
@@jakub.gaik.official Yes, it's still super useful, especially for coordinating CI. Basically, if you find yourself doing npm run build && npm run typecheck && npm run test I usually reach for turbo.
i have question related to pnpm if you could help when using pnpm it install shared deps in nested node-modules folder in .pnpm inside main node-modules for some reason i need to import type sfrom packages that not top level ..is there a way to do that without setting the shamfully-hoist=true in .npmrc ( if somthing wrong with my explantion ..that's cause i recently switched to pnpm ..and trying to migrate)
You'll need to specify the dependencies you need inside the packages where you need them - that's part of pnpm's philosophy. Implicit dependencies are bad.
Is any one can help me for starting a big project? That's a admin panel that includes more than 200 pages and it should handle more that 10 individual parts. Do I should use monorepo? micro-frontend? there is no limit in using stack except angular.
I'll never understand Monorepos. It becomes a huge mess even with few developers, and it gets infinitely worse with more developers. Keep your projects small and to the point, each in their own repository.
Monorepos are for keeping projects small but dependencies uncomplicated. Pulling the latest from the repo will automatically sync all of your projects together and can be built together in whatever combination you need. Otherwise you have to keep your various projects in sync and coordinate a lot more between teams to sync
Let us assume we have a react package under /packages/core_package. (This is where most of the development happens) We are using this package in an app under /apps/website How can we setup a hot reload functionality here to view changes in the app ? Should we build the package each time and then run the app or is there a better way ? Any help would be greatly appreciated. Thank you 🙏
@@mattpocockuk I see, I like yarn workspaces but if it also makes installs faster that's pretty good! Come to think of it, doesn't turborepo do the workspaces thing?
This man’s content is always golden. Unlike theo and prime ranting about the most random crap
Do you have it somewhere on github working?
What cannot be overlooked is how you provide types from your libraries to apps. If you do it as an npm package would do, via .d.ts files, you have to always rebuild the library with tsc after any modification, for the changes to be picked up by other parts of the monorepo. If you decide to point to .ts source code, you are able to skip this step, at the cost of tsc analysing your library source code even when type-checking the app, additionally imposing the same „strictness” between the compiler options (the app cannot be stricter than the library it uses).
This is all pretty trivial with this setup. Turbo handles rebuilds. No need to point to .ts source code (which doesn't work for publishing anyway).
also pointing to ts code has the downside that all code must be directly under the package root. If you were to add a _src_ folder, you'd have to type that out as well into the import path.
@@xN811x That isn't true, you can use "exports" in package.json to point to ts code, normal imports will work fine.
This is where we landed at my company. We were using nx, but I found it to be too much of a blackbox and config heavy for our use case. We landed on a top level dir of libs/ with a single tsconfig.json file that is the most strict (so that it can be pulled in by our apps/ code). It does give tsc more work to do, but it's not that bad.
Same here, we also considered using nx to combine a react native and next.js app into a monorepo. I decided to keep it super simple and use pnpm and instead of each package having a build step just add to the tsconfig includes for each app. Works really nice and we don’t publish any of our packages anywhere, they’re just shared between those apps.
Super great and to the point. It would be cool if you did a series incrementally adding only the most beneficial packages for a project to have. I believe that would be very informative
add a `shell.nix` to automatically install turbo and pnpm for you and then your machine only needs one system dependency
@@nekony3563 "why do you need gcc if you already have apt"
vs devcontainer?
turborepo isn't supported by nix though, or vice versa, idk
@@PanagiotisChatzigiannis but it's a rust workspace -- you could easily build a nix derivation for it and post it on nixpkgs
Great overview - thanks Matt!
Great I’m starting a monorepo for a domain driven project i have in mind and this will help a lot
Matt Pocock is my favorite dev youtuber
Matt long time no see, nice to see your news vids
Hi, great video. This is the exact setup I implmented for our current project at work several months ago. It would be great to see some more details on the Turborepo. The documantation is good but the setup is not trivial
Better than nx I'd say
There is the big war on turbo vs nx..
I personally like `nx` but I am not against turbo, I have just not seen any clear reason of why I would switch, so I just stick with what I know.
Though, I do like that we have 6 completely independant apps that interlink externally from, so it's nice to use the `nx` tagging system to say `serve the tag:code-name` apps, or `serve the tag:legacy`
It may depends on the FW we’re using. For instance, with Angular, nx is perfect as it comes with a lot of tools.
For Vue, it’s a tad more of a struggle. While with Turbo, it’s pretty easy.
(From what I’ve experimented, at least)
@@tmbarral664 We use Vue.. NX seems perfectly fine.. To be honest, if you are using Angular, using Turbo vs NX is the least of your worries.
Using the exact same base setup for close to two years now 😁
@mattpocockuk would you be able to suggest a similar set up with NX? A short video like that one would be great ❤.
this video makes me think i picked the right dependencies thanks for the confidence boost now all i need to do is settle on a js framework
What I've come to find has trouble scaling is the "internal" packages you'd build continually with --watch. Monorepo really encourages you to put whatever you can in a separate package and having to build all of these each time you change anything becomes really cumbersome as you scale up. Not to mention stuff like fast-reload, which does become a bit harder to set up. I've started going down the rabbit hole of exporting the main TS file directly in "internal" packages, but that comes with its own set of issues.
To be fair I don't have any answers here. It feels like this area is still not well thought-out.
moreover, tsc --watch will take over the flow and the turbo command will never end
He's back babyyyyy!
bun could technically replace all of those deps - bun works in monorepo setup, is fast & doesn't require transpiling from TS to JS (hence no need for turbo) and supports TS out of the box.
Definitely couldn't replace tsc or turbo
@@mattpocockuk where do you see Bun coming up short? I'm looking at the features pages side by side and not seeing the gap.
I would add tsup to build in ESM + CJS (and you need to setup package.json imports property)
Disagree, ESM-only is the new meta now.
@@mattpocockuk i really would like that all people think like you
Now that Node allows require(ESM) we're good to go!
thanks for the video... do you have one where you show how to configure prism with a turborepo ?
if not, would you be willing to make a practical video? please?
Turbo repo vs nx, any thoughts ?
both are good, use whatever you prefer
We are using nx in our company (without DTE) and we are very happy with it. Moreover we pay 0 💵.
(I am the author of nx-remotecache-gcp) so we store the cache in Google Buckets.
Private package registry > turbo/nx
Both are good, I'm more familiar with Turbo (having worked at Vercel as their devrel)
We used NX for awhile at my company and ultimately migrated away from it about 18 months ago. The situation may be somewhat better now, but our biggest pain points were:
1. VERY config heavy, with poorly documented options in the JSON files. There was a lot that you could do, but we wound up having to review the actual NX source code because some features weren't even mentioned in the docs.
2. Commingled dependencies. All projects share a SINGLE package.json in the project root. If project A depends on React@16 but project B needs React@18, you're SOL. There's no way to (sensibly) migrate one project at a time. This also has weird implications for Intellisense as you might get hinting suggestions for React packages when you're working on the API.
Very similar to what we use in winglang
Why use turborepo if the goal is minimize deps? Could just use npm workspaces
Turborepo doesn't do workspaces, pnpm does. Turborepo is a task runner - absolutely crucial in my eyes.
Did not get to like turborepo, however, nx is just pure awesomesness!
how do you use it for dev/local env where you want to restart the Node automatically whenever either an app or a library code got changed?
Add biome to make it perfect
How are PRs managed in large monorepos?
For example, I get the idea of using a monorepo for building a design system but when we add something like `/apps` to it; Are we adding "real" apps to the monorepo as well? and if this is the case, if you have 8-10 apps using your design system, how are PRs managed?
what would your first choice for testing be in this kind of setup?
Vitest
the biggest pain in a monorepo setup is the watch mode. In the given example, if you run a certain package in watch mode, the watcher will only listen to files within that package. It won't re-build on monorepo dependencies change. I wonder what's your typical solution to this problem.
A root-level tsconfig with specified paths is kind of a solution, but it requires paths to be manually maintained, which doesn't play nicely with the philosophy of a monorepo where packages are supposed to be self-contained.
That's a very generic description of a problem, if the package doesn't have dependencies within the monorepo then why should it rebuild?
This is what turborepo is for - only running the dev tasks required for a specific app.
@@mattpocockuk Would it be more efficient or faster to use TypeScript's project references to run a single watch mode over the app and its packages?
@@nekony3563 It's debatable, but I prefer Turbo because it can cache any bundler and the config is more portable/modular.
@@ra2enjoyer708 I meant exactly that scenario where a package being watched depends on another monorepo package. Why would I rebuild otherwise?
Why not Bun? Lint, test, typescript, and more in the same runtime. Doesn’t get any cleaner than that!
Bun isn’t exactly prod ready yet sadly 👀
Not sure what it adds here
can you please share a starter for chrome extension with typescript
This can’t be happening right now. I spent 5 days fighting my tsconfig to build my honojs api and I gave up and used eabuild 6 hours before this video dropped 😂.
Awesome video as always!
This looks very easy to use, and I would be tempted to try it. However, I've gotten so used to Deno (and have actually crafted a small monorepo setup that works for me), that I kinda don't wanna go back to plain Node.js?
Is there a way to combine Deno and Monorepo?
I'm sure there is! Not used Deno yet
How would you handle UI libraries & CSS imports for building with TSC? Simplicity of this setup is unmatched but a bit lost on that front
What specific requirements do you have?
You won't use this minimalistic setup then - you'd need a bundler e.g. esbuild
My favorite kind of monorepo is one that doesn't even have a package.json in the root of the repository. The folder structure is as follows:
apps/
app1 ... appN/
packages/
package1 ... packageN/
Each app and package is essentially "isolated" with their own package.json files, and the packages are all published and versioned to a private registry.
You can remove the turbo dependency using `tsc --build`. You'll get a lot of the same advantages, right?
Turbo can run and cache other tasks, like tests/app builds too.
tsc -b is good, but turbo is better.
It always start with three and ends with a thousand 😢.
Why not bun?
As few deps as possible
It's funny... watching this inspired me to give one of my personal projects a tidy up... but I ended up using a completely different tool kit to yours... ... "completely different"? ... ... well not quite.... ... it's got to have typescript right? ... ... right!
Nice! What did you use?
@@mattpocockuk it wasn't a monorepo or anything: yarn, vitest, tsx, tsc, 11ty-3.0-alpha, eslint, stylelint, prettier... not exactly "minimal" either ;)
How do you handle external deps? Eg you have multiple libs all using a 3rd party. Do you use the root package.json or per library imports and then have to deal with the version syncing explicitly per package. We currently use the root approach as easier to maintain but I can’t help but think it is killing build times as everything now has everything in its package.json. E.g. Monaco editor is huge and now all our projects have it in their packages due to it being in the root one. There is very little guidance on this in the docs…..
Why would having a package in your node modules affect your build? If it's not requested by that app it won't be part of the code parsed for the build.
The only way it would slightly slow things down is the install step.
That said, I do recommend that all runtime dependencies are installed in the closest package.json. Implicit dependencies suck.
I am curious why you are choosing to go with pnpm? You don't really go into the why of that one. npm recently got caching similar to pnpm, so I am not sure what other reasons there are to use it. testing locally, I do save a fraction of the time using pnpm, but I am just not sure it is worth it
In what version did npm get pnpm-like caching? Want to read up on it before I answer.
Well especially in a monorepo where packages are published I really enjoy the `workspace:` protocol, as it reduces churn. NPM plain doesn't support that.
Could you show a setup where the "package" uses React? I want to use React there to e.g. write reusable hooks that are then used in the apps.
Add "jsx" to your tsconfig.json. That's it!
@@mattpocockuk Thanks :)
What about ESLint? It's great but seems to be a bit of a mess right now. Flat config with separate config files doesn't work with turborepo.
ditch eslint and prettier for biome. only one dep, no longer do we need to install typescript-eslint and its million plugins
@@apteryx I heard that it's pretty experimental and missing tons of rules
Once you try out Biome and see the insane speed you will never want to go back to eslint
I am fight with that and shadcn into ui to get correct type, I adjusted but see like workaround
TRPC same, added as package but now with server and client components we need split the exports right ?
How would you compare it with nx ?
big if tru
With this setup, does each project run type checks on all dependencies as well as itself? How do you run type checks in this setup without doing a lot of duplicative work?
Nope, type checks only run on source code in that package.
@@mattpocockuk Interesting. Is that because of workspaces? How are type checks scoped to the package without using composite and references?
@@davidhouse3448 skipLibCheck: true
As a jQuery developer, I'm offended that it wasn't mentioned.
jQuery was implied
Does anyone have a github repo for this setup to refer to
Do You even need turbo or nx? Npm supports workspaces without any dependencies
Yes, running tasks in a monorepo is a massive pain. Caching the result of the tasks is an enormous speed boost.
Hmm if I were to build something like a component library or utils library where the monorepo is just for bundling everything in one place would it make sense to use such tools
@@jakub.gaik.official Yes, it's still super useful, especially for coordinating CI.
Basically, if you find yourself doing npm run build && npm run typecheck && npm run test I usually reach for turbo.
i have question related to pnpm if you could help
when using pnpm it install shared deps in nested node-modules folder in .pnpm inside main node-modules
for some reason i need to import type sfrom packages that not top level ..is there a way to do that without setting the shamfully-hoist=true in .npmrc
( if somthing wrong with my explantion ..that's cause i recently switched to pnpm ..and trying to migrate)
You'll need to specify the dependencies you need inside the packages where you need them - that's part of pnpm's philosophy. Implicit dependencies are bad.
@@mattpocockuk thanks for your repsonse ,specify them in package.json as deps correct ?
@@peteremad5228 Yes!
Is any one can help me for starting a big project? That's a admin panel that includes more than 200 pages and it should handle more that 10 individual parts. Do I should use monorepo? micro-frontend? there is no limit in using stack except angular.
Doesn't sound like a monorepo - one big app.
@@mattpocockuk You mean I should use a single repo and go with it?
@@erfansamani Yep
Now throw react native in there
Now just to install 200 npm dependencies to handle the most common TS tasks lol
Can you use graphql tada in monorepo?
Yes!
@@mattpocockuk when I do that, I lose typesafe from vscode.
This not work with me, I try many times and after a lot of search I can't do that. If you have time you can try it to see that
I'll never understand Monorepos. It becomes a huge mess even with few developers, and it gets infinitely worse with more developers. Keep your projects small and to the point, each in their own repository.
Monorepos are for keeping projects small but dependencies uncomplicated. Pulling the latest from the repo will automatically sync all of your projects together and can be built together in whatever combination you need.
Otherwise you have to keep your various projects in sync and coordinate a lot more between teams to sync
Let us assume we have a react package under /packages/core_package.
(This is where most of the development happens)
We are using this package in an app under /apps/website
How can we setup a hot reload functionality here to view changes in the app ? Should we build the package each time and then run the app or is there a better way ?
Any help would be greatly appreciated. Thank you 🙏
This is what turbo is for
3:30 You forgot the holy grail Svelte 😡😡
(great mono tho)
What does pnpm add to this?
Makes package install faster, handles workspaces.
@@mattpocockuk I see, I like yarn workspaces but if it also makes installs faster that's pretty good!
Come to think of it, doesn't turborepo do the workspaces thing?
It’s been awhile
Imagine run dev in big monorepo, wouldn’t recommend that
Works for nextjs.
This is what turborepo is for - running only the dev tasks needed for a specific app.
You don't even need to build.
Not sure what you mean, but - yes, you do.