system instructions: for a project, is “knowledge” suypposed to work like system instructions? my experience is, it does not.
dependencies: by way of example, v0 continues to call dependencies that are not available in v0 - even if my system instructions are clear not to. Further, I asked v0 for what it has on offer, and it included things that are not supported in the v0 environment. Seems it’s very clear that you folks are using a generic model and that model does not seem to remember you folks, or you are not including everything in your system instructions you need to.
chats: what is best practice. They have no knowledge of the project for which they are contributing, and how to share across chats, or gather context from other chats (and system instructions). for example, we have a chat for our API integration which we want isolated from the other chats and share the API access, but the other chats don’t seem to be able to use the shared API layer - even explicit prompting.
Okay, that’s a start. I don’t know if this means we are pushing the boundaries or just not getting it. Either way, your help would be greatly appreciated.!-- Questions that get answered the fastest are the ones with relevant info included in the original post. Be sure to include all detail needed to let others see and understand the problem!
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:
Native Node.js APIs: You cannot use APIs that read or write to the filesystem directly
CommonJS-only modules: Dependencies that only implement CommonJS and don’t support ES Modules may not work properly.
Dependencies using native Node.js APIs: Any npm packages that rely on Node.js native functionality like file system operations won’t work.
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.
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