Turborepo Demo and Walkthrough (High-Performance Monorepos)
HTML-код
- Опубликовано: 25 июл 2024
- Turborepo is a high-performance build system for JavaScript and TypeScript codebases. This demo shows how to set up your first Turborepo, intelligently cache build outputs, enable remote caching through Vercel, and achieve optimal performance with your monorepo.
0:00 - Introduction / Announcement
1:10 - Jared Palmer / Turborepo Background
3:45 - Overview
4:13 - Demo
7:29 - Monorepos
9:10 - Turborepo
14:47 - Dependency graph generation
15:30 - Task Graph Pipeline
18:19 - Profiling in Chrome
22:49 - Remote Caching
29:00 - Q&A
29:10 - Where can you store the remote cache?
31:36 - Can Turborepo help improve things like GitHub Actions for CI/CD or a Heroku build in production environments?
32:11 - Are the tasks all running in parallel inside one process?
32:42 - Does Turborepo allow you to do incremental compilation or ‘watch mode’ compilation of multiple multiple local typescript packages?
34:02 - Will it fail gracefully if it can’t access remote cache (builds locally)?
34:17 - How does caching work if node_modules contain different artifacts (e.g.: Sharp for Linux & Widows would be different). But the source (lock file) will have the same fingerprint?
36:19 - How do you prevent security issues with people uploading malicious build results?
37:36 - Does Turborepo cache entire workspaces; or can it also cache individual files?
38:11 - How do you share UI if there are different frameworks in your other projects?
39:06 - How is the loss of internet connection handled on the client when running tasks in a Turborepo that has remote cache enabled?
39:13 - What is the ideal architecture of monorepos - how would you structure having multiple packages, or multiple pieces of your larger frontend?
41:07 - What are some of the big advantages of Turborepo (vs other monorepo systems and how you’ve designed it?
43:06 - If I’m using another tool, like Lerna, it’s essentially 20 lines of code and a few minutes and you can incrementally bring it into your codebase?
44:35 - Will Turborepo adopt pnpm and do you recommend that tool as well?
45:55 - Can you have a Turborepo inside of a Turborepo so that each of my giant app ecosystems is a Turborepo inside a Turborepo?
47:12 - In an enterprise with developers of different skill sets - how easy is this to adopt? What is the learning curve?
48:08 - What’s next / We’re hiring!
◆ Try Turborepo: turborepo.org
◆ Vercel Acquires Turborepo: vercel.com/blog/vercel-acquir...
◆ Deploy Turborepo to Vercel: vercel.com/docs/concepts/git/...
#turborepo #monorepo 
Развлечения
Very straightforward idea, brilliantly executed! And you are just getting started, so awesome!
loved the stream. Somehow I feel proud to be a developer looking at you guys.
Super exciting stuff, can't wait to try it out!
This was awesome. Really excited to try it. My only feedback is, that the whole presentations felt a little unstructured (maybe Jared was just super excited to show ALL the features). I'd also would have loved to see how to run deployments with Turborepo & Vercel. Thanks for putting this out!
Very cool. I think the end game of this approach is being explored by the folks working on the Unison language (the granularity goes down to the language/expression level) - but they should make it work for all languages. Also you made some good decisions about 'getting out of the way', which is nice compared to NX.
Remote caching is about to change Vercel costs with cloud, because if you ran the build locally with remote cache, the vercel infra just have to download the cache and deploy, instead of paying for a Lambda to build the entire app. That is 🤯🤯🤯, congrats Turbo and Vercel.
I agree, sort of, with Nx's plugin concepts and it causing "friction". I think it is a hurdle to getting started for sure. At least it was for me. And so hats off to wanting to make it easy to start with Turborepo. The only thing that seems new is the remote caching. Very interesting. I'll be keeping an eye on Turbo repo (we are using Rush currently and are happy).
Amazing!
This is awesome!
Vercel always try to provide best developer experience.
bhai tu ek saal pehle yeh dekh raha tha. 😅
@@RahulinWeb3 Haha! Yeah bro
Awesome!!
The only think that i dont like about next.js and monorepo architecture is that you need yo use third parties transpilers, such next-transpile-modules, for share components between apps. You cannot freely update next version if the library does not already support that version, and what if the third party library goes unmaintained? imho a native way to share components between apps would be awesome.
Pretty cool!
This is great, I have one question regarding ENV variables.
So, some of the build systems actually replaces the ENV vars with it's actually literal values in the build output, so If I build the project locally and turbo uploads the cache.
What happens when we build on production where the ENV variables are different ?
+1 bumping for notifications
good question
Awesome
Local & Remote cache is awesome, most of the features crossing with nx, what is the main feature of turborepo that beat other competitors?
First of all, great presentation, I liked it. However, TBH, I've been working for ~3 years with Nx and I did not see anything new, instead I see Turbo as a little child compared to Nx. I wish you the best and I hope you bring more features to the table, you have a big guy to beat.
They have a strong team but I also agree and hope they put the effort in to add value
I have a mono repo with 25 packages, lerna and yarn v1, it’s good, what would be better with nx?
Well, if you structure your project very well the advantages are many, you build only what's affected, you can add tags for scoping each project, also you get computational caching, you can integrate other projects apart from TS/JS. Definitely you should try it out
does someone know if i can add a react project inside the app directory ? I need to have a separate react app as well as a next js app inside the app folder and both will have a common ui package that they talk to
I've been playing around with turborepo, and I'll say, its a great time saver. Another question 😊, turborepo come with few commands, build, dev, lint, format, how do I run start in production for a specific app in production when I have multiple apps?
Also something I would like to know! :D
@@wesleyjanse6600 from my experience, you can change the start command to cd in to the app you want to run start command on, and mom start for Ex. cd web && npm start
@@hakanaki Alright, so you would build the entire monorepo, then just only start the needed app. and you could I guess also dockerize this on build to remove the not needed apps?
@@wesleyjanse6600 correct me if I'm wrong, but on the video they mentioned that it won't build what it doesn't need to build. Running build the first time will build everything, but on the second build, it only have to what has been changed.
You can also control what app to start from config files, such as heroku, netlify, travis, circle ci config files
So let's say, I have multiple webshops that need to look and feel the same, and use the same components. But need to be deployed and build separately. Is that something that can be done using turborepo?
Would you please put some repo url in the description? I am almost sure 87.6% of the people using this and watching this video needs it
How does this compare to nxjs which has a bunch of caching stuff to keep it fast?
11:18 👏
Where can I find the "turborepo-starter" code from 13:40?
It would be awesome if there were more resources to really understand how to structure turbo repo projects, if you are new to it there are very few videos that explain the basics. I have read through the docs and watched all the videos but for some reason I’m not grasping it well.
Same here. A bit more simplification would be great. Having problems running it with PNPM and its hard to find out why or how to structure it so it works.
Which platform did you use for this online meeting? It has a nice user interface 😲
I'd like to see Turborepo integrated into a NestJS monorepo. How to make both play together nicely?
I think the tasks mainly depends on the package.json's scripts. Like turbo build will lookup build script in all apps.
can use it in react native cli project and react vite app with typescript?
Vercel is awesome. Thanks @Vercel
What does VERCEL mean btw?
What VSC theme is it? I need it!
Turborepo 😆🤣🤣Super cool name.
NX or Turborepo for Next.js?
Nx ofcourse. Turbo is very new at the moment and Nx provides way too many awesome functionalities. Turbo right now is a minor subset of Nx
How do I run remote cache on -prem? I'm not allowed to upload our whole codebase to the cloud.
yeah lage is pretty good
Seems scary to share a cache with everybody on the team and CI. If one developer gets hacked, couldn't an attacker infect every other developer (by changing the build output of the express server for example)? Also, couldn't an attacker manipulate a release artifact this way without anybody noticing?
Edit: At 36:19 they discuss security.
I'm not sure that he did a great job with the explanation and I think you're concerns are valid
🤯
Can you use this with plane react without next?
Yes! Turborepo works with any frontend framework, shared configs, or other packages like component libraries.
@@VercelHQ Okay, Thank you
What's the difference between Turborepo and NX ?
I think that Turbo is more transparent, NX have more features, but it's more complex to use and configure. It's like ride a bike with no training wheels.
@@GabrielLopesbiutas I think....
Presenting from a WeWork?
Damn remote caching sounds dope. What a idea to share artifacts across developers but how will it work for platform specific artifact outputs
hi im a beginner what does an artifact means?
@@deamorta6117 it simply means output of build it can be a exe file, image screen shot, test results.
@@technikhil314 ohhh yeah ive been seeing this term everywhere but does not know what it means. THAAAANKS
the same code ,build time used 39.716s, why?
So TurboRepo only works with JS repos right? No .NET core?
Overall very cool, though obe thing I think is the weak dedign is the approach to pipelines.
It reminds me of Maven vs. gradle and also TeamCity vs. Jenkins Pipelines. From my experience it backwards rrasoning of what needs to be done before something else is NOT intuitive and makes a lot of confusion.
Jared should have looked at those I mentioned, TeamCity has similar approach and was always confusing.
When we moved to Jenkins pipeline, a procedural approach was way way easier to reason for us as devs, as it is the normal approach (algorithms) we use to reason in our codes in a daily basis
Any reason for using golang instead of rust.
Cause it’s a CLI and not a critical application that requires safe memory access
wow, visual studio sln for front end...
I can image Nrwl/Nx engineers screaming at the screen every couple of minutes: "We did that years ago."
i see vitejs i press like
None seem to have come across something called nx. Or victor savkin or anything remotely to do with angular framework. Lol
NX was pissing me off with config, this looks great alternative
I'm sorry to hear that Nx's config was aggravating for you, do you have examples of the pain points you encountered?
For transparency I'm a core contributor on the team and have been heavily involved with recent improvements to Nx's config. Starting in 13.3 which released yesterday only 1 file is mandatory (nx.json)
@@AgentEndercake yes yesterday was hellish for my team we suffered a lot due to cli bug doesn't build projects parallel stopped working we needed to downgrade cli to 12.7.0 and what the hell "nx format" this even caused another whole level of shit...any after wasting fixing downgrading resolved thanks
@@AgentEndercake Really? Man, that's killer news. I'm on my 3rd Nx project, been using and promoting Nx for various teams I join. I love it when onboarding and/or training up a new team, it has so much great tooling. However, recently I've had a ton of issues with Nx not recognizing importPaths and instead requiring very long relative paths. The importPath actually works once compiled, but if I don't use the relative path Storybook, Jest and CI fail I tried a fresh build to test that issue isolated and had the same result. Extremely frustrating as well as testing errors for files that were long deleted or for file that exist, but Nx believes them to be missing. I'm going to try 13.3 immediately.
So glad I dropped in here, knew someone would try to compare these 2 and it paid off. Thanks!
@@effinrich The relative paths should definitely not be required, it sounds like there is a misconfiguation w/ your tsconfig or potentially a custom webpack config going on. I don't have a ton of context in that area, but feel free to open an issue and someone can help out.
Same, can't figure out how to build a prod app of a nestjs app because the ENV keeps undefined after the build. So frustating
Also, look, turborepo doesn't appear to work as the docs say, idk i may be a dumb, idiot, dunce, like really stupid, but the fact is i have done EXACTLY what the docs say (as i perceive them) and I'm lost in a deep deep dark hole of dispair.........maybe show like 7 different examples of how to integrate it into a project quickly and just leave the warts on the videos. We don't need or WANT perfect videos, we want to see how you stumble into the right thing.
Please, and thank you very much, we really appreciate all you do!
@Turborepo guy Jared or whatever your name is, look great you have created the greatest monorepo thing in existence EVER in all the history of MANKIND, now its time to SHOW PEOPLE HOW IT WORKS, this means simply do ONE thing, make about 25 or 30 videos showing how to work with it, stumble around in front of us, fail in front of us, WE WILL ALL FAIL LEFT AND RIGHT
if you want us to use it GREAT, SO DO WE
HELP US understand by showing us VIA video
just do it 50x in different ways, just get on a video and show us how to work your sh## stuff
A solution to a problem I don’t have. Using ESM for everything = 0 ms.
Is this an NX ripoff?
Both Turborepo and NX are meant to be more accessible versions of the extremely complicated Bazel and Gradle.
See it as competition, not as a copy
Lol, nope, if turborepo has built their build automation around yarn and npm workspaces. They're already behind the curve. I know people think npm workspaces are the way to do monorepos, but what if i told you you could do everything turborepo does, without workspaces, symlinks and achieve sub second build times?
Spill the beans