Hi Jared, I'm currently working on Commitspark, a headless CMS that uses vanilla GraphQL to define the content model and GitHub for storage and workflows. With this approach I can already today use ChatGPT to not only generate a website content model from a user prompt (e.g. "I want a component-based website with a hero component with title and image, a product component with article number, ...") but also entire web page content from user prompts (e.g. "I have this marketing text here, turn it into content data for a web page using the components in my content model: ...").
The perfect addition here would be to also enable users to generate React components that visualize each content component (I was able to prototype that already with ChatGPT, but I assume what you're doing is more advanced).
Wrap all of this up into a Git repo with Vercel deployment workflow for GitHub and it should be possible to go from prompt to CMS-driven website in a really short time.
So, my question: Would it be possible to get access to V0? Also, feel free to reach out if you see potential for collaboration.
v0 saves loads of time by allowing you to quickly generate UIs with React via Shadcn UI (https://ui.shadcn.com) with simple text prompts. While full scale design tools are very useful, not every UI in your app needs that level of fidelity. Furthermore, a lot of UIs inside of apps and websites are already extremely programmatic (such as forms, tables, modals, etc.). The goal with v0 is to get you started (hence the name) faster....to give you something you can copy and paste and then modify yourself.
Hi everyone! Jared Palmer (https://x.com/jaredpalmer) here from the v0 team and Vercel. Happy to answer any questions. The team is very excited to finally share what we've been working on with the community. We know it's early, but as the name implies... it's v0.
I'm super excited in graphing this over time. Will be interesting to see how the providers develop over the coming months.
FWIW we also need TTFB not just tokens per second. The first token is key for UX
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.
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.
Can Prune be used to build a bundle (as in a zip) for, say AWS Lambda, which includes only the dependencies (and not dev dependencies)? I've played around with pnpm's deploy but it felt a bit lackluster. Especially talking about situation where one has a backend package and some shared package. The bundle should contain all dependencies (but not dev dependencies) of the backend package and shared package and of course the built shared package should also be include in the bundle's node_modules.
You can do that with esbuild. Just bundle the handler entry into a single file and esbuild will tree shake the cruft out. That's the approach taken by AWS CDK as well.
Yeah, that always works, of course, even though you might want to externalize certain dependencies still. In this case I don't want to bundle the code (although I might end up doing that, anyway)
You can give esbuild a list of dependencies that you want to be external and it won’t bundle them, I’ve done it with the AWS SDK and it works as expected.
That's correct. However, I've tried to use prune now, not sure if I am using it correctly, but that's why I do:
I build my packages regularly (not pruned), then I prune with scope "backend". Apparently the pruned directory contains node_modules with empty packages, not sure what reason is for that; I just ignored it. In the resulting directory I then run `pnpm install --prod`. Only the regular dependencies will be installed. I think this is enough for my usecase. I am not sure if prune is supposed to be used for this approach though.
> * 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.
> However, it sounds like you like to see glob fan out of tasks.
Yes, the idea here being that I don't want to list all similar tasks (such as linting) explicitly in the turborepo config. Teams should be free to add any additional lint task if they think it's useful for them (and possibly only for them). Similar to Maven(Java) where additional goals can be bound to the standard lifecycle phases.
Happy to answer any questions!