Become a TypeScript Wizard with my free beginners TypeScript Course: www.totaltypescript.com/tutor... Follow Matt on Twitter / mattpocockuk Join the Discord: mattpocock.com/discord
Пікірлер: 132
@kszyh_28 күн бұрын
Do you have it somewhere on github working?
@AbstruseJoker26 күн бұрын
This man’s content is always golden. Unlike theo and prime ranting about the most random crap
@Endrju21928 күн бұрын
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).
@mattpocockuk28 күн бұрын
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).
@xN811x28 күн бұрын
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.
@mattpocockuk28 күн бұрын
@@xN811x That isn't true, you can use "exports" in package.json to point to ts code, normal imports will work fine.
@brianpetersen722728 күн бұрын
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.
@AdamK3l28 күн бұрын
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.
@dpklabs28 күн бұрын
Great overview - thanks Matt!
@hugazo28 күн бұрын
Great I’m starting a monorepo for a domain driven project i have in mind and this will help a lot
@user-gm9es6vr9w28 күн бұрын
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
@jenreiss310728 күн бұрын
add a `shell.nix` to automatically install turbo and pnpm for you and then your machine only needs one system dependency
@jenreiss310728 күн бұрын
@@nekony3563 "why do you need gcc if you already have apt"
@novailoveyou27 күн бұрын
Matt long time no see, nice to see your news vids
@gm11228 күн бұрын
Matt Pocock is my favorite dev youtuber
@rafaeltab28 күн бұрын
He's back babyyyyy!
@syedamz457426 күн бұрын
@mattpocockuk would you be able to suggest a similar set up with NX? A short video like that one would be great ❤.
@joestrkr27 күн бұрын
Using the exact same base setup for close to two years now 😁
@bernardstein165128 күн бұрын
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
@v_r_to_c_n825128 күн бұрын
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
@brianpetersen722728 күн бұрын
Better than nx I'd say
@user-lc3un9jw8t28 күн бұрын
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.
@mattpocockuk28 күн бұрын
Definitely couldn't replace tsc or turbo
@tarunpai212127 күн бұрын
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?
@cristianpallares756528 күн бұрын
Very similar to what we use in winglang
@yiannis_p28 күн бұрын
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!
@antontimeboy609428 күн бұрын
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?
@mattpocockuk28 күн бұрын
I'm sure there is! Not used Deno yet
@tichopad27 күн бұрын
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.
@prasinar133728 күн бұрын
what would your first choice for testing be in this kind of setup?
@mattpocockuk28 күн бұрын
Vitest
@ColinRichardson28 күн бұрын
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`
@tmbarral66428 күн бұрын
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)
@ColinRichardson28 күн бұрын
@@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.
@megamind45227 күн бұрын
can you please share a starter for chrome extension with typescript
@sadn1ck28 күн бұрын
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
@mattpocockuk28 күн бұрын
What specific requirements do you have?
@DefekacjaOdbyta28 күн бұрын
You won't use this minimalistic setup then - you'd need a bundler e.g. esbuild
@zwanz0r28 күн бұрын
You can remove the turbo dependency using `tsc --build`. You'll get a lot of the same advantages, right?
@mattpocockuk28 күн бұрын
Turbo can run and cache other tasks, like tests/app builds too. tsc -b is good, but turbo is better.
@Cassp0nk27 күн бұрын
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…..
@mattpocockuk27 күн бұрын
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.
@cristobalcontrerasrubio469528 күн бұрын
I would add tsup to build in ESM + CJS (and you need to setup package.json imports property)
@mattpocockuk28 күн бұрын
Disagree, ESM-only is the new meta now.
@cristobalcontrerasrubio469528 күн бұрын
@@mattpocockuk i really would like that all people think like you
@mattpocockuk28 күн бұрын
Now that Node allows require(ESM) we're good to go!
@kunal.burangi26 күн бұрын
How would you compare it with nx ?
@davidhouse344828 күн бұрын
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?
@mattpocockuk28 күн бұрын
Nope, type checks only run on source code in that package.
@davidhouse344828 күн бұрын
@@mattpocockuk Interesting. Is that because of workspaces? How are type checks scoped to the package without using composite and references?
@mattpocockuk28 күн бұрын
@@davidhouse3448 skipLibCheck: true
@hiagooliveira651028 күн бұрын
Turbo repo vs nx, any thoughts ?
@SergiySev28 күн бұрын
both are good, use whatever you prefer
@JohnZakaria28 күн бұрын
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.
@onlywei28 күн бұрын
Private package registry > turbo/nx
@mattpocockuk28 күн бұрын
Both are good, I'm more familiar with Turbo (having worked at Vercel as their devrel)
@joelv449528 күн бұрын
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.
@apteryx28 күн бұрын
Add biome to make it perfect
@peteremad52284 күн бұрын
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)
@mattpocockuk3 күн бұрын
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.
@peteremad52283 күн бұрын
@@mattpocockuk thanks for your repsonse ,specify them in package.json as deps correct ?
@mattpocockuk3 күн бұрын
@@peteremad5228 Yes!
@real-oppenheimer26 күн бұрын
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.
@mattpocockuk25 күн бұрын
Add "jsx" to your tsconfig.json. That's it!
@real-oppenheimer25 күн бұрын
@@mattpocockuk Thanks :)
@Boha36227 күн бұрын
Why use turborepo if the goal is minimize deps? Could just use npm workspaces
@mattpocockuk27 күн бұрын
Turborepo doesn't do workspaces, pnpm does. Turborepo is a task runner - absolutely crucial in my eyes.
@zilahi826 күн бұрын
Did not get to like turborepo, however, nx is just pure awesomesness!
@carlosricardoziegler265028 күн бұрын
I am fight with that and shadcn into ui to get correct type, I adjusted but see like workaround
@carlosricardoziegler265028 күн бұрын
TRPC same, added as package but now with server and client components we need split the exports right ?
@erfansamani27 күн бұрын
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.
@mattpocockuk27 күн бұрын
Doesn't sound like a monorepo - one big app.
@erfansamani27 күн бұрын
@@mattpocockuk You mean I should use a single repo and go with it?
@mattpocockuk27 күн бұрын
@@erfansamani Yep
@rinart7328 күн бұрын
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.
@apteryx28 күн бұрын
ditch eslint and prettier for biome. only one dep, no longer do we need to install typescript-eslint and its million plugins
@rinart7328 күн бұрын
@@apteryx I heard that it's pretty experimental and missing tons of rules
@henrikskog290928 күн бұрын
Once you try out Biome and see the insane speed you will never want to go back to eslint
@upbeatstable27 күн бұрын
@@henrikskog2909 yeah dude just wish they update faster. I love the performance but there are a lot of things missing. Also the auto import delete is freaking annoying. It auto removes unused import on save but what I'm just the middle of coding it. I think a better option would be to show warning on dev then only auto delete on commit
@xorlop28 күн бұрын
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
@mattpocockuk28 күн бұрын
In what version did npm get pnpm-like caching? Want to read up on it before I answer.
@jonkoops28 күн бұрын
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.
@mohammedhuzaifa865427 күн бұрын
Does anyone have a github repo for this setup to refer to
@DefekacjaOdbyta28 күн бұрын
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.
@ra2enjoyer70828 күн бұрын
That's a very generic description of a problem, if the package doesn't have dependencies within the monorepo then why should it rebuild?
@mattpocockuk28 күн бұрын
This is what turborepo is for - only running the dev tasks required for a specific app.
@nekony356328 күн бұрын
@@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?
@mattpocockuk28 күн бұрын
@@nekony3563 It's debatable, but I prefer Turbo because it can cache any bundler and the config is more portable/modular.
@DefekacjaOdbyta28 күн бұрын
@@ra2enjoyer708 I meant exactly that scenario where a package being watched depends on another monorepo package. Why would I rebuild otherwise?
@GekonisPL28 күн бұрын
Do You even need turbo or nx? Npm supports workspaces without any dependencies
@mattpocockuk28 күн бұрын
Yes, running tasks in a monorepo is a massive pain. Caching the result of the tasks is an enormous speed boost.
@GekonisPL28 күн бұрын
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
@mattpocockuk28 күн бұрын
@@GekonisPL 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.
@duttaoindril28 күн бұрын
Why not bun?
@mattpocockuk28 күн бұрын
As few deps as possible
@Mohammed_school_s28 күн бұрын
Can you use graphql tada in monorepo?
@mattpocockuk28 күн бұрын
Yes!
@Mohammed_school_s28 күн бұрын
@@mattpocockuk when I do that, I lose typesafe from vscode.
@Mohammed_school_s28 күн бұрын
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
@stefan.astrand28 күн бұрын
Why not Bun? Lint, test, typescript, and more in the same runtime. Doesn’t get any cleaner than that!
@user-fr2fm3ri3w28 күн бұрын
Bun isn’t exactly prod ready yet sadly 👀
@mattpocockuk28 күн бұрын
Not sure what it adds here
@_bug5628 күн бұрын
What does pnpm add to this?
@mattpocockuk28 күн бұрын
Makes package install faster, handles workspaces.
@_bug5628 күн бұрын
@@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?
@srivatsav1128 күн бұрын
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 🙏
@mattpocockuk28 күн бұрын
This is what turbo is for
@PRonYouTube26 күн бұрын
big if tru
@onlywei28 күн бұрын
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.
@edgeeffect27 күн бұрын
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!
@mattpocockuk27 күн бұрын
Nice! What did you use?
@edgeeffect27 күн бұрын
@@mattpocockuk it wasn't a monorepo or anything: yarn, vitest, tsx, tsc, 11ty-3.0-alpha, eslint, stylelint, prettier... not exactly "minimal" either ;)
@Fik0n28 күн бұрын
Now throw react native in there
@wvovaw305228 күн бұрын
As a jQuery developer, I'm offended that it wasn't mentioned.
@mattpocockuk28 күн бұрын
jQuery was implied
@dandogamer28 күн бұрын
Now just to install 200 npm dependencies to handle the most common TS tasks lol
@Virgoblack9728 күн бұрын
It’s been awhile
@mahadevovnl27 күн бұрын
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.
@onthefence92827 күн бұрын
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
@scaffus28 күн бұрын
3:30 You forgot the holy grail Svelte 😡😡 (great mono tho)
@lacherolachero940928 күн бұрын
Imagine run dev in big monorepo, wouldn’t recommend that
@ra2enjoyer70828 күн бұрын
Works for nextjs.
@mattpocockuk28 күн бұрын
This is what turborepo is for - running only the dev tasks needed for a specific app.