system instructions

Yes, the project instructions under the "knowledge" tab in your project settings are like system instructions. I've had good results with specifying file conventions and structures to follow, as well as referencing files (like uploaded cursor rules)

dependencies

Dependencies are handled at runtime by the esm.sh CDN (this is an implementation detail so it might not be true forever, for anyone reading this later), so it's not possible for v0 to have an exhaustive list of all libraries that will work with it. If this was hardcoded it would miss out on lots of potential lesser known libraries that do work with it

With that in mind, v0's response to the question might make more sense in context

Unsupported Dependencies in v0

When working with v0's Next.js runtime (which powers the Code Projects), the following types of dependencies are not supported:

1. Native Node.js APIs: You cannot use APIs that read or write to the filesystem directly
2. CommonJS-only modules: Dependencies that only implement CommonJS and don't support ES Modules may not work properly.
3. Dependencies using native Node.js APIs: Any npm packages that rely on Node.js native functionality like file system operations won't work.
4. Dynamic code evaluation: The following JavaScript features are disabled

chats

Chats are all independent of each other, but they live under the project. Each v0 project is a Vercel project, and you can consider each chat to be like a branch of that, so if it would make sense to do in separate branches, it would make sense to do in separate chats.

If you're working on separate things, like an API and an integration, then you should either put them in the same project, such that all your chats have both of them, or keep them in separate projects, then you can deploy one and access it as a backing service via environment variables.

thank you for the comprehensive answer.

Does v0 have plans to enable chats to "recognize / talk to each other" in v0 without having to deploy? Context windows are larger, and this "branch mentality", does not really translate to UX designers and non coders (note: I am familiar with the concepts, 20 years software). I am just saying, in my opinion, a v0 user shouldn't need to understand Git - in my view. They should focus on UX and v0 should just work. I recognize how v0 came from Vercel, and that is the land of software development. However, v0 can serve and attract and work easily for more people if this mental model was not imposed on the user.

Also, can you share anything of the vision? Strikes me, for the v0 audience (ie prototypers) or folks who want to a front end project on v0 (hint: ideally all the way if the backend lives elsewhere). I personally believe this could be at hand or closer that you folks ever imagined, but if it's not where you are going, that's something I want / need to know.

Can you share more about what you would use this shared chat context for? I can think of two reasonable features

• LLM context only, so you can ask one chat "copy the header design from Chat 123" and it knows where to look that up
• monorepo style projects where one chat is the deployed project, and it can import components and functions from the others. I think this would be tricky to avoid breaking the dependent chats

v0 is not just for prototypers or for front end projects. It has a growing ecosystem of DB, infrastructure, and AI integrations from the Vercel marketplace. There are projects running in production that live entirely within v0

The latter. To facilitate maintain ability / scale. Given one chat works - till it doesn’t.