Ein bestehendes Vue-Projekt verstehen

Vue Codebase & Version Discovery

Verify the project's actual Vue, TypeScript, router, state, server-bridge and build versions and conventions from its manifests and source before proposing or writing code.

1. Versions, manifests and tooling

• Read package.json, the lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock*) and tsconfig*.json / vite.config.* before assuming any framework API exists:
  • Vue: Vue 3.5+ (useTemplateRef, reactive props destructuring, onWatcherCleanup, useId), Vue 3.4 (defineModel stable, :id shorthand), Vue 3.3 (<script setup generic="T">, defineOptions, defineSlots, toRef/toValue), or Vue 2.7 / Options API.
  • Bridge & routing: @inertiajs/vue3 (v1 vs v2 <Deferred>, <Form>, usePoll, whenVisible), vue-router (v4 vs unplugin-vue-router typed routes), or Nuxt.
  • State & utilities: pinia, @vueuse/core, @tanstack/vue-query, form libraries (vee-validate, zod), and i18n (vue-i18n or custom catalog).
• Collect the exact scripts the repo defines for typecheck (vue-tsc), lint, build and test (vitest, playwright).
• When version-specific behavior is uncertain, inspect the installed package types in node_modules or the official docs for that exact version.

2. Existing components, composables and tokens

• Map the frontend layout: pages/views, shared UI primitives, domain components, composables (use*), stores, API/Inertia helpers and types. Resolve path aliases (@/, ~/) from tsconfig and vite.config.
• Inspect 2–3 sibling components and composables in the area you will touch to match conventions: <script setup lang="ts"> vs Options API, block ordering, prop/emit typing style, and styling (Tailwind, scoped CSS, CSS Modules, design tokens).
• Reuse existing UI primitives (buttons, inputs, dialogs, tables, toasts, empty/error states) and composables (@vueuse/core or local use*) before creating new ones.

3. State ownership and data flow map

• Trace the user flow end to end and classify every piece of data with a single source of truth:
  • Server data: page props from Inertia or responses from API queries.
  • URL state: route params, search filters, sort order, active tab or pagination that should survive reload or link sharing.
  • Local UI state: open/closed toggles, form drafts and transient modal state kept in the narrowest owning component.
  • Shared client state: cross-route session or workspace state that genuinely belongs in Pinia or scoped provide/inject.
  • Derived state: values computed via computed(), never duplicated in a second ref synced by watchers.

Before you finish

• package.json, lockfile, tsconfig and build config checked; exact Vue, router, Pinia and Inertia versions known.
• Existing components, composables, styling tokens and i18n conventions inspected and reused.
• Server data, URL state, local UI state, shared state and derived values classified with one owner each.