vue0: a Vue flavoured open source take on the v0.dev prompt to UI tool

A Vue answer to a React shaped question

vue0 describes itself as the Vue version open source alternative for v0.dev, and the homepage is vue0.dev. The name is the obvious one, and the intent is stated plainly: the same idea, an interface where a natural language prompt produces a user interface, but producing Vue rather than the React output of the original.

The stack is the clearest evidence that this is a real application rather than a sketch. It is a Nuxt 3 project, with `@nuxt/content` for documentation content, `@nuxtjs/tailwindcss` for styling, `radix-vue` and `lucide-vue-next` and `radix-icons/vue` for the component primitives, and `class-variance-authority` with `tailwind-merge` and `clsx`, which is the shadcn-vue component recipe.

The `components.json` file at the repository root and the `template/shadcn-vue/` directory referenced by the npm scripts point at the same conclusion: the component output follows shadcn-vue conventions, meaning generated components are source files you own rather than imports from a package.

The repository is MIT licensed with the LICENSE file at the root, and the primary language is Vue. The homepage is vue0.dev and the repository is not archived, with the last push on 2026-04-23. There are no GitHub releases, so the application is run from source rather than installed from a published artefact.

The generation pipeline is a checklist, not a design document

The most informative part of the README is the execution plan, which is a task list with checkboxes rather than a prose description of the architecture.

The completed items describe the shape of the pipeline clearly. Generating metadata as JSON for a component comes first, then a multi-pass step, then iteration steps, then storing components on the filesystem, and then rendering the generated code. That is a pipeline where the model is called more than once, each pass refining what the previous one produced, and the intermediate metadata is kept as structured data rather than thrown away.

Then there is the user side of it: a user feature was added, support for forking components was added, there is screen capture of the generated component, simple metadata handling, and improved caching.

The screen capture item is interesting because of the dependencies. `puppeteer-core` appears in the dev dependencies, and the environment file has a `NUXT_BROWSERLESS_API_KEY`, which points to a hosted browser service being used to render the generated component into an image. That is a screenshot pipeline, not local rendering, and it explains the otherwise odd combination of a Nuxt application depending on a browser automation service.

Four items are unchecked: support for image upload, referencing the GPT-4 and GPT-4 Turbo model documentation, improving user feedback for iteration, and allowing local hosting without GitHub OAuth. Those are the honest gaps, and the third one in particular, better feedback during iteration, is the difference between a usable loop and a frustrating one.

The `js-tiktoken` dependency is a small but telling detail. Token counting matters when you are structuring a multi-pass pipeline against a model API, because you need to know how much of the context you are spending on each pass.

Getting it running locally takes four steps

The development setup is documented in the docs section of the README and is short enough to reproduce exactly.

Clone the repository, install the dependencies with pnpm, start the dev server, and open the local address:

pnpm i

pnpm dev

http://localhost:3000

The dev script is `nuxt dev`, and the README notes that it runs Nuxt 3. The other scripts follow the standard Nuxt set: `nuxt build`, `nuxt generate` for static output, `nuxt preview`, and `nuxt prepare` as a postinstall step so the generated types exist before anything else runs.

Two of the scripts are specific to this project and explain a lot about it. `download:repo` runs `cd template && jiti downloadRepo`, and `parse:repo` runs `jiti template/shadcn-vue/parseMeta`. Both operate on the `template/` directory, which is where the shadcn-vue component source is kept. The parse script is the one the execution plan calls generating metadata JSON for a component, and the download script pulls the component source down. The pairing of a downloader and a parser over a template directory is the mechanism behind the fork and metadata features.

For the database there are Drizzle scripts: `drizzle-kit generate:sqlite` for migrations and `drizzle-kit studio` for the database browser. `drizzle.config.ts` sits at the repository root alongside a checked-in `db.sqlite` file.

Linting is handled by ESLint with the `@antfu/eslint-config`, and the `lint` and `lint:fix` scripts cover the whole project.

The environment file reveals what the app talks to

The `.env.example` file is short and tells you exactly which external services the application depends on.

NUXT_OPENAI_API_KEY=<if provided no need to input the key on the client-side>
NUXT_OAUTH_GITHUB_CLIENT_ID=
NUXT_OAUTH_GITHUB_CLIENT_SECRET=
NUXT_SESSION_PASSWORD=

NUXT_BROWSERLESS_API_KEY=
NUXT_PUBLIC_SITE_URL=http://localhost:3000
 
TURSO_DB_URL=
TURSO_DB_TOKEN=

Four services appear. The OpenAI key drives generation, and the comment on that line is a design decision worth noting: if the key is provided server side, the user does not have to supply one on the client side. That is the sensible arrangement for a hosted deployment, and it is also the difference between a shared deployment and a per-user local setup.

GitHub OAuth provides accounts, which connects directly to the unchecked execution plan item about allowing local hosting without GitHub OAuth. The app currently assumes GitHub sign-in, and the plan says that should change. `NUXT_SESSION_PASSWORD` is the session secret, and `nuxt-auth-utils` is the matching dependency in the dev dependencies.

The Browserless key is the screenshot service discussed above. The Turso variables point at Turso, the hosted SQLite service, which pairs with the `better-sqlite3` and `@libsql/client` dependencies and the Drizzle ORM at ^0.29.2. The local development path uses the `db.sqlite` file that is already committed at the repository root, and the Turso variables are how you would move the same schema to a hosted database.

`NUXT_PUBLIC_SITE_URL` is the only variable with a public prefix, and it is set to the local development address.

Where the project is still unfinished, and what that means for you

The execution plan tells you which parts are done and which are not, and the four unchecked items are concentrated in the areas that matter most for using the tool day to day.

Image upload is not supported, which limits the prompts you can use. If you want to say what a generated component should look like, you cannot hand it a picture.

Iteration feedback is listed as needing improvement. The iteration steps are in the pipeline, and the fork feature works, but the loop of refining a component through several passes is the part that has not been polished. For a tool whose entire value is the iteration loop, that is the item to watch.

Local hosting without GitHub OAuth is not done, so the account system is tied to GitHub. For a team running this internally, that means every user needs a GitHub account, which is friction that a local deployment should not have.

A separate point about the generated output itself. Because components follow shadcn-vue conventions, they are source files that live in your project rather than imports from a package. That is the good case: you own the code, you can edit it, and there is no runtime dependency on the generation service afterwards. The corresponding cost is that the components you get are only as good as the template the project started from, and generated code tends to be uniform, so a codebase built entirely from generated components will look generated.

The alternative to adopting this code is to use the hosted service it is modelled on, or to build the same pipeline yourself against a model API. The difference in approach is that the hosted service gives you a finished product with none of the infrastructure decisions, while this repository gives you the pipeline, the schema and the templates and leaves the deployment, the cost of model calls and the account system to you.

Editorial conclusion

Adopt vue0 if you want to read or extend a working open source implementation of prompt to component generation for Vue, and are comfortable running a Nuxt 3 application with your own OpenAI key and a SQLite or Turso database. Do not adopt it as a hosted product without reading the environment configuration first, because the example file carries a placeholder for the OpenAI key and an explicit note that a client side entry is skipped when one is provided. Verify first which features are actually done, since the execution plan in the README leaves image upload, iteration feedback and local hosting without GitHub OAuth unchecked.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zernonia/vue0 on GitHub