Gemini CLI Vue.js: A Practical Setup for Vue Projects

Gemini CLI can be a practical coding agent for Vue.js projects when you start it from the project root with gemini and give it a focused GEMINI.md. It reads Vue single-file components, edits Composition API code, and runs your Vite, Pinia, and Vitest workflows. This guide assumes a Vite project with Vue 3, Pinia, and Vitest, and focuses on the decisions that make the agent more reliable. See Gemini CLI for the core agent workflow, then apply the Vue-specific loop below.

What makes Gemini CLI useful for Vue codebases

Gemini CLI is terminal-based, so it sits next to the same commands a Vue developer already uses: npm run dev, npm run test:unit, and npm run lint. That matters because the agent can act on the whole project, not just a single file open in an editor. In a Vue project, real changes often touch three files at once: a single-file component, a Pinia store, and a Vitest spec. Gemini CLI can follow those cross-file changes when your GEMINI.md names the conventions.

It also handles template, script, and style sections as one unit. For example, asking it to replace an Options API component with <script setup> means updating bindings, props, emits, and test imports together. That reduces the chance of leaving a test that still targets the old component contract. Because GEMINI.md is read at session start, it can also encode Vue-specific lint rules, such as no Options API and no direct state mutation outside Pinia actions. That prevents the agent from introducing patterns your team already rejected. The agent benefits from fast feedback: after it edits, you run Vitest immediately, and the failure output tells it exactly which Vue Test Utils assertion or reactivity assumption broke.

Give the agent your project rules with GEMINI.md

Add a GEMINI.md file at the repository root. Keep it short enough to be read at the start of a session, but specific enough that the agent does not guess Vue conventions. For a Vite + Vue 3 project using Pinia and Vitest, the file should name the commands, folders, component style, state boundaries, and test expectations.

Here is a realistic GEMINI.md for a Vue.js project:

# GEMINI.md
# Commands
npm run dev        # start Vite dev server
npm run build      # production build
npm run test:unit  # Vitest with Vue Test Utils
npm run lint       # ESLint

# Vue.js project conventions
- Use Vue 3 Composition API with `<script setup>` in single-file components.
- Do not introduce Options API components.
- Use Pinia for shared or cross-component state; local UI state stays in the component.
- Keep components in `src/components` and composables in `src/composables`.
- Name SFC files with PascalCase and use kebab-case in templates.
- Each component's props and emits must be typed with `defineProps` and `defineEmits`.
- When changing behavior, also update or add a Vitest test with Vue Test Utils.
- Prefer `shallowMount` for unit tests and `mount` only when the test needs child rendering.
- Run the targeted test file first, then `npm run test:unit`.
- Do not reformat unrelated code.

# Testing notes
- Mocks live in `src/test/mocks`.
- Use `flushPromises` from Vue Test Utils after triggering asynchronous store actions.

The commands shown are for npm; replace them with pnpm or yarn equivalents if your lockfile differs. Keep the file under about one screen so the agent actually follows it instead of skimming. For the general session workflow, see How to use Gemini CLI: a step-by-step guide.

Plan small, edit, test, review

Use a small-step loop: plan, edit, verify, review. Ask the agent to read the relevant files and propose a plan before it writes code. Then approve a narrow implementation. Run the targeted Vitest file after each change, and inspect the git diff before asking for the next step.

Example prompts for typical Vue.js tasks:

• Read src/components/CheckoutForm.vue and src/stores/cart.ts. Find where an empty-cart message should appear without changing the cart store API. Propose a diff first.
• Add a useCartTotals composable in src/composables/useCartTotals.ts that reads the cart Pinia store and returns subtotal, tax, and total. Keep the existing component markup unchanged.
• Update ProductCard.vue to accept a typed product prop and emit add-to-cart from its button. Add a focused Vue Test Utils spec with shallowMount.
• In src/stores/auth.ts, replace direct localStorage access with a storage helper and add a test that creates a fresh Pinia instance before each test.
• Run npm run test:unit -- src/components/ProductCard.spec.ts, fix any failing assertions, then run the full unit suite.

These prompts give the agent a file path, an exact behavior, and a verification target. They avoid asking for a broad feature all at once. If the agent proposes a large refactor, ask it to split it into a component change, a store change, and a test change. That makes each diff reviewable.

Where Gemini CLI shines and where it slips in Vue

Gemini CLI is strong for structured Vue refactors, but you should review the diff for Vue-specific mistakes rather than trusting the first output.

When a diff touches reactivity, ask the agent to explain the ownership of state before accepting it.

Keep the Vitest loop tight

Testing is where Gemini CLI earns its keep, but only if you treat the test command as the source of truth. After the agent changes a component or store, run the narrow spec first, for example npm run test:unit -- src/components/ProductCard.spec.ts. Then run the full suite and lint.

For Vue Test Utils, insist on a few rules in GEMINI.md. Always create a new Pinia instance with createPinia() in beforeEach so store state does not leak between tests. Use flushPromises() after an async store action or watcher, and use await nextTick() only when the DOM must update. Prefer shallowMount for component unit tests to keep assertions focused on the component under test. Ask the agent to run the precise failing spec after a failed run and to include the assertion output in its explanation. If the project uses global plugins like Vue Router or Vue I18n, note in GEMINI.md that shallowMount must pass global.plugins or use a custom render helper. Without that, the agent may write tests that fail only in CI.

Also watch for tests that pass for the wrong reason. A spec that only checks wrapper.text() may miss a broken computed property or a missing event payload. Ask for one assertion that covers the contract, not just the markup. The agent should update tests in the same change as the implementation, not in a separate cleanup pass.

Parallel Vue workstreams with AgentVera

AgentVera can help when a Vue.js project has several workstreams, such as a Pinia store refactor and component test coverage. It runs Gemini CLI alongside other real command line agents in separate terminals and git worktrees, so parallel edits do not overwrite each other. When an agent’s turn ends, a second model reviews the code and links findings to file:line, which catches Vue reactivity mistakes. Checkpoints let you undo a bad turn, and token budgets keep an agent from burning through a large refactor unnoticed. See AI agent team: a manager, roles and handoffs for how roles and handoffs work.

Final advice for Vue.js teams

Gemini CLI is most useful on a Vue.js project when you invest a few minutes in GEMINI.md and stay close to the test loop. Let it do the mechanical refactors and first-draft tests, but review every diff against your component contract and Pinia state boundaries. See AI pair programming: how to work with a coding agent for a broader workflow for working with a coding agent.