We're investigating this now. Early experiments are very promising.
303 karma · joined May 8, 2013
Happy to answer any questions!
Tailwind is indeed required at the moment. However, we're working on supporting other popular design systems as well as custom ones.
Link: https://v0.dev | FAQ: https://v0.dev/faq
Side-by-side comparison of LLama 2, Claude 2, GPT-3.5-turbo and GPT: https://sdk.vercel.ai/s/EkDy2iN
As part of the project, I’ve been working with providers and hosts on updating their SDKs to work on Vercel Edge Functions (and streaming).
It works automatically when you use the `app` directory in 13.2+. No additional steps are needed when you self-host/run on Node.js
We do not invalidate the whole graph anymore for a lockfile change. We now have a sophisticated parser that can calculate if a change within the lockfile should actually alter the hash of a given target. In addition to higher cache hit rates, this is what powers our `turbo prune` command which allows teams to create slices of their monorepo for a target and its dependencies…useful for those building in Docker.
Prune docs: https://turbo.build/repo/docs/reference/command-line-referen...
Turborepo is much more scalable now than when we spoke pre-Vercel acquisition. It now powers the core web codebases at Netflix, Snap, Disney Streaming, Hearst, Plex and thousands of other high-performance teams. You can see a full list of users here: https://turbo.build/showcase
Would be happy to reconnect about Uber’s web monorepo sometime.
> * tasks on the root package (e.g. tsc -b that typechecks all packages)
We are working on this as we speak! The first step is to add the ability to restrict hashing `inputs`[1] to the Turborepo `pipeline`. After that we are going to be adding root task running in the next minor release.
However, as your monorepo grows, you will likely want to move away from running tasks like tsc from the root and instead run them on a per-package basis. The reason is that tools like Bazel, Buck, Turborepo, etc. can become more incremental (and thus faster) as your dependency/task graph becomes more granular (as long as you maintain or reduce the average affected blast radius of a given change). The other argument against root tasks is that they break hermeticity and encapsulation of the package abstraction. That being said, root tasks are very useful for fast migration to Turborepo and also for smaller repos. Futhermore, we're happy to tradeoff academic purity for productivity with features like this.
> treat tasks such as lint:eslint, lint:pretter as a single task lint (or maybe `lint:*`)
You can run multiple tasks at the same time and Turborepo will efficiently schedule them at max concurrency.
turbo run eslint prettier --filter=@acme/...
However, it sounds like you like to see glob fan out of tasks. This is a really cool idea. I created a GitHub issue for it here [2] if you'd like to follow along.
Yes, it's possible. Databricks currently uses both Turborepo and Bazel together in their monorepo[1]
[1] https://twitter.com/elado/status/1504216742393876483?s=20&t=...
Turborepo author/founder here....
I agree. I built Turborepo because existing tools weren’t meeting our needs.
To solve these problems and still be flexible, many existing build tools end up with lots of configuration bloat. We’re trying to avoid that. We want to reimagine the developer experience of monorepo tooling and make it accessible for everyone.
Well said. Perhaps my deeper point is that hooks and soon Concurrent Mode force devs to come to terms with the fact that they _don't_ understand React internals (hence my usage of black box) and that their mental models were wrong this whole time (although some might argue still pretty productive).
I also think Crank is SUPER interesting on so many levels. I built a few demos with it and am fairly impressed. However, practically speaking (and I'm putting my developer relations hat on), I think its generator API is just too intimidating to junior developers.
I know Facebook has an internal CSS Module thing that is not open source ready. So this has been pushed off to user land. However, lack of an officially blessed style solution makes React components less reusable across projects compared to Vue. Thanks to vue-loader, the Vue community can focus on other things. I am NOT advocating for single file components like Vue, I am hoping that FB can just bless a solution so we can move forward as community.