GO — Healthy across the board

• Last commit 1w ago
• 28+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 69% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

Pinia is a type-safe, Vue 3 state management library built on the Composition API that replaces Vuex. It provides intuitive store creation with DevTools support, featuring a modular design where stores are individual but interconnected—similar to how a pineapple is made of individual flowers joined together. Core capability: define reactive stores with defineStore() that work seamlessly with TypeScript and Vue 3's reactivity system. Monorepo structure using pnpm workspaces: packages/pinia/ contains the core store implementation, packages/nuxt/ provides Nuxt 3 integration, packages/testing/ offers testing utilities, and packages/docs/ is a VitePress documentation site. Core state logic lives in TypeScript modules under packages/pinia/src/, with separate entry points for different module systems.

Vue 3 developers building medium-to-large applications who need centralized state management without Vuex's boilerplate. Also targets Nuxt 3 developers via the dedicated @pinia/nuxt package. Contributors are primarily Vue ecosystem maintainers and TypeScript enthusiasts.

Highly mature and production-ready. The project is officially endorsed by Vue.js (vuejs/pinia GitHub organization), has a comprehensive test suite running via Vitest with coverage tracking, active CI/CD pipelines (.github/workflows/), and TypeScript-first implementation. Currently on v4 with v2 branch still maintained for Vue 2 compatibility.

Very low risk. Backed by the official Vue organization with clear governance, strong test coverage (vitest + codecov integration), and well-defined contribution guidelines (.github/CONTRIBUTING.md, commit conventions). Single points of concern: maintainer capacity (though this is standard for open-source), and the dependency chain through Vue 3 upgrades. No red flags in maturity or abandonment.

Active v4 development with Vue 3.5+ support. Recent workflow automations for releases (release-tag.yml), sponsor updates, and pkg.pr.new integration for preview deployments. Documentation is being actively maintained in multiple languages (en.ts, zh.ts configs). TypeScript build optimization underway (oxfmtrc.json formatter config present).

git clone https://github.com/vuejs/pinia.git
cd pinia
pnpm install
pnpm run dev

Then open the Vitest UI on localhost (shown in terminal). For docs: pnpm run docs starts the VitePress development server.

Daily commands: Dev with tests: pnpm run dev (starts Vitest UI with coverage). Build: pnpm run build (compiles pinia, nuxt, and testing packages). Docs: pnpm run docs (VitePress dev server at localhost:5173 by default). Full test suite: pnpm run test (runs types, vitest, package tests, builds, then dts validation).

• package.json — Root monorepo configuration defining workspaces for pinia, nuxt, testing, and docs packages.
• packages/pinia — Core Pinia store library—the main package that implements the reactive store system with composition API.
• .github/CONTRIBUTING.md — Contributor guidelines covering commit conventions, testing expectations, and development workflow.
• .github/workflows/ci.yml — CI/CD pipeline configuration that runs tests, builds, and validates releases across the monorepo.
• packages/docs/introduction.md — Official documentation introducing Pinia concepts, making it essential to understand design philosophy.
• packages/docs/core-concepts — Directory containing guides on state, getters, actions, and plugins—core abstractions every contributor must understand.

• defineStore() (Vue 3 Composition API, ref, computed) — Factory function returning a composable that creates or retrieves a singleton store instance with reactive state.
  • Failure mode: Returns undefined or stale instance if called outside component setup or before pinia initialization.
• Reactive State (ref/computed) (Vue 3 reactivity, Proxy, WeakMap) — Vue reactivity system tracking mutations and triggering component re-renders.
  • Failure mode: Lost reactivity if state is destructured without reactive() wrapper; manual ref unwrapping required in templates.
• Plugin System (pinia.use()) (JavaScript closures, object inspection) — Hooks intercepting store creation and action execution to enable persistence, logging, and validation.
  • Failure mode: Plugin side effects execute for all stores; unhandled async in plugins can cause race conditions.
• DevTools Integration (window.VUE_DEVTOOLS_GLOBAL_HOOK, postMessage) — Subscribes to store mutations and action calls, relaying timeline and state snapshots to Vue DevTools browser extension.
  • Failure mode: DevTools unavailable if extension not installed; performance degradation with millions of mutations.
• Pinia Instance (createPinia()) (Vue 3 provide/inject, createApp().use()) — Root container managing store registry, plugin queue, and DevTools setup; must be installed before store usage.
  • Failure mode: Stores fail to initialize if pinia not installed; separate instances create isolated state silos.

• Vue Component → defineStore() — Component calls useMyStore() composable to access store instance.
• Component Action Call → Store Mutation — User-dispatched action modifies reactive state via direct assignment or mutations.
• Reactive State Change → Computed Getters & Components — State mutations trigger getter recomputation and component re-renders via Vue's dependency tracking.
• Store Mutations → Plugin Hooks & DevTools — Plugin system subscribers and DevTools extension listen to all mutations for logging, persistence, or inspection.
• Async Actions → External APIs — Actions can fetch data from REST/GraphQL APIs; developer handles loading/error state in action functions.

Add a new Store (Basic Pattern)

1. Create a new store file in your app or example directory using defineStore composition API. (packages/pinia/src/stores/yourStore.ts (follow pattern from core-concepts/state.md))
2. Export the store and use it in components with useYourStore(). (packages/docs/core-concepts/state.md (reference implementation))
3. If adding to Pinia core tests, create a test in packages/pinia/tests matching store functionality. (packages/pinia/tests (follow existing test structure))

Add a Plugin or Middleware

1. Implement a plugin function that receives the pinia instance and returns a function accepting a store context. (packages/docs/core-concepts/plugins.md (reference and examples))
2. Register the plugin in your app using pinia.use() or in packages/pinia/src for core plugins. (packages/pinia/src (main plugin registration system))
3. Add tests validating plugin initialization, store hooks, and side effects. (packages/pinia/tests (plugin test patterns))

Add Documentation or Migration Guide

1. Create a new Markdown file in the appropriate docs section (cookbook, core-concepts, or ssr). (packages/docs/cookbook or packages/docs/core-concepts)
2. Update the VitePress config to include the new doc in sidebar navigation. (packages/docs/.vitepress/config/shared.ts or language-specific config)
3. Run docs build and verify rendering with pnpm docs:build. (packages/docs/package.json (docs build scripts))

Add a Test Case for Core Functionality

1. Create a test file in packages/pinia/tests matching the feature being tested. (packages/pinia/tests (follow Vitest patterns in existing tests))
2. Import utilities from @pinia/testing or packages/testing for mocking store state. (packages/testing (testing utilities))
3. Run tests with pnpm dev and ensure coverage targets are met. (package.json (dev script with coverage))

• Vue 3 Composition API — Native reactivity system via refs/computed eliminates boilerplate and provides type safety without custom decorators.
• TypeScript — Enables full type inference for store state, getters, and actions without manual type annotations.
• Monorepo (pnpm workspaces) — Separates concerns (core, Nuxt integration, testing) while sharing documentation and release infrastructure.
• Vite + Vitest — Fast ES modules-first build and test runner aligned with Vue 3 ecosystem and modern JavaScript.
• VitePress — Static site generator optimized for Vue documentation with zero-config search and i18n support.

• Composition API-only (no class-based Options API stores)

  • Why: Cleaner migration path from Vuex; aligns with Vue 3 direction.
  • Consequence: Incompatible with Vue 2; requires developers to learn functional patterns rather than familiar class syntax.

• Lightweight core with plugin system instead of built-in features

  • Why: Keeps bundle size minimal and allows optional DevTools, persistence, etc.
  • Consequence: Developers must understand plugin architecture for advanced use cases; plugin ecosystem fragmentation risk.

• Auto-subscriptions and reactivity proxies rather than explicit getters/setters

  • Why: Reduces boilerplate and leverages Vue's reactivity transparently.
  • Consequence: Implicit behavior can make performance debugging harder; requires DevTools for visibility.

• Separate @pinia/testing and @pinia/nuxt packages

  • Why: Optional dependencies reduce core bundle size and prevent version conflicts.
  • Consequence: Users integrating with Nuxt/testing must explicitly install packages and configure imports.

• Does not handle authentication or authorization—those are application-level concerns.
• Not a real-time database—assumes unidirectional data flow; does not sync across browser tabs natively.
• Does not provide GraphQL, REST, or API client abstraction—integrates with any async library (fetch, axios, tRPC).
• Not a form state management solution—users should combine with VeeValidate or similar for complex forms.
• Does not enforce immutability patterns—relies on developer discipline and DevTools monitoring.

• Avg cyclomatic complexity: ~6 — Core store logic is straightforward (state wrapping + proxy), but plugin system, DevTools integration, and reactive binding introduce coupling and indirect control flow.
• Largest file: packages/pinia/src/store.ts (estimated ~600-800 lines) (750 lines)
• Estimated quality issues: ~3 — Type safety excellent via TypeScript; main issues are plugin system opacity (implicit hooks), sparse error messages in edge cases (missing pinia install), and documentation gaps on performance tuning for large stores.

• Destructuring store state without reactive wrapper (High) — packages/docs/core-concepts/state.md (common mistakes section): Directly destructuring store properties breaks reactivity; must wrap with storeToRefs() or access via store proxy.
• Calling useStore outside component setup/actions (High) — packages/docs/core-concepts/outside-component-usage.md: Invoking useStore() outside reactive context (e.g., in event handlers before mount) returns stale or undefined instance.
• Synchronous logic in actions without loading states (Medium) — packages/docs/core-concepts/actions.md: Actions should explicitly manage loading/error flags for UI feedback; implicit async breaks optimistic updates.
• Plugin side effects without error handling (Medium) — packages/docs/core-concepts/plugins.md: Unhandled exceptions in plugin hooks silently fail; plugin authors must wrap async in try/catch.
• Excessive computed getters in large stores (Low) — packages/pinia/src (no explicit guidance): Computed properties are cached but still subscribed per component; too many can degrade reactivity performance.

• Plugin system execution during store initialization (Initialization latency) — All registered plugins execute synchronously on createStore(); heavy plugins (persistence, validation) block store creation.
• DevTools mutation logging with high action frequency (Runtime performance) — Each mutation posts message to DevTools extension; apps dispatching 100s of actions/sec risk browser stalling.
• Large state object reactivity in defineStore() (Memory & reactivity overhead) — Deep reactive proxies on stores with thousands of properties trigger unnecessary re-renders; alternative: create sub-stores.
• Synchronous test fixture setup in packages/testing (Test performance) — createTestingPinia() clones entire plugin queue; heavy plugin-laden apps slow test suite parallel execution.

TypeScript strict mode required: All packages use strict: true in tsconfig.json; untyped code will fail CI. Monorepo build order matters: Must run pnpm run -C packages/pinia build before other packages; direct pnpm install in subdirectories can cause workspace resolution issues. DevTools bridge version-specific: Works with Vue 3.5+ only; v2 branch targets older Vue versions via separate DevTools adapters. No magic module names: Unlike Nuxt auto-imports, Pinia stores must be explicitly imported or registered via Nuxt plugin—check packages/nuxt/src/module.ts for expected export patterns.

• Composition API Store Factory Pattern — Pinia's entire API centers on defineStore() as a factory function; understanding reactive function composition and closure-based state encapsulation is essential to using Pinia effectively
• Reactive Proxy Objects (Vue Reactivity) — Pinia stores are automatically reactive via Vue's Proxy-based reactivity system; understanding how state mutations trigger re-renders is critical for debugging unresponsive UIs
• DevTools Bridge Protocol — Pinia implements a custom DevTools adapter (packages/pinia/src/devtools/) to communicate state snapshots and actions to browser extensions; useful for debugging time-travel and action replay
• Tree-shaking & Module Federation — Pinia stores are individually exported and tree-shakeable; only used stores are bundled into production builds via ES module design in packages/pinia/src/
• Monorepo Workspace Management with pnpm — Pinia is a pnpm monorepo with multiple interdependent packages; understanding workspace linking and build order is essential for local development and running tests
• TypeScript Strict Mode & Generic Constraints — Pinia is fully typed with strict TypeScript; stores use generics for state, getters, and actions; understanding type inference and constraint patterns is critical for avoiding type errors
• Plugin Architecture & Middleware Pattern — Pinia supports plugins that hook into store creation and subscription lifecycle; understanding this extensibility pattern is key for adding custom logic like persistence or logging

• vuejs/vue — Pinia depends on Vue 3's Composition API and reactivity system; Vue core changes directly impact Pinia compatibility
• vuejs/router — Vue Router is the official router used alongside Pinia in typical Vue 3 SPAs for full app state and navigation management
• nuxt/nuxt — Pinia has first-class Nuxt 3 integration via @pinia/nuxt package; Nuxt projects use Pinia as the default state manager
• reduxjs/redux — Predecessor pattern inspiration; Pinia simplifies Redux's concepts (actions, mutations, state) into a single API without boilerplate
• pmndrs/zustand — Alternative lightweight state manager; Zustand targets React while Pinia targets Vue 3, both emphasizing minimal boilerplate over Vuex/Redux

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive E2E tests for Nuxt module integration

The repo has a packages/nuxt subdirectory (referenced in build scripts) but no visible E2E test workflow in .github/workflows. Pinia's Nuxt integration is critical for the ecosystem, and E2E tests would verify auto-imports, plugin registration, and composable detection work correctly across Nuxt versions. This prevents regressions in a high-dependency integration point.

• [ ] Create .github/workflows/e2e-nuxt.yml to test packages/nuxt against multiple Nuxt versions (v3.x)
• [ ] Add test fixtures in packages/nuxt/test/fixtures/ with minimal Nuxt projects
• [ ] Verify auto-import of useStore() composables, plugin initialization, and devtools integration in Nuxt context
• [ ] Run E2E tests on PRs targeting packages/nuxt to catch breaking changes early

Add missing unit tests for packages/testing module

The build script references packages/testing (pnpm run -C packages/testing build) but there are no test files visible in the file structure. As this is a first-party testing utility for Pinia stores, it needs comprehensive tests for testCreatePinia(), testPinia() helpers, and mock store behavior. This ensures reliability for downstream projects using Pinia testing.

• [ ] Create packages/testing/tests/ directory with test files matching src/ structure
• [ ] Add tests for mock store creation, state mutations, action mocking, and plugin composition
• [ ] Add tests verifying isolation between test runs (no state leaking)
• [ ] Run vitest coverage to ensure >80% coverage for packages/testing

Document and add type tests for Plugin API with real-world examples

packages/docs/core-concepts/plugins.md exists but the repo lacks .test-d.ts files demonstrating correct plugin TypeScript usage. Contributors extending Pinia with plugins often struggle with typing context, pinia instance, and store augmentation. Adding DTS tests (using packages/pinia/tests for reference) would catch type regressions and serve as living documentation.

• [ ] Create packages/pinia/tests/plugins.test-d.ts with type assertions for common plugin patterns (store augmentation, context typing, pinia access)
• [ ] Add test cases for plugin generics with and without type arguments to catch inference issues
• [ ] Update packages/docs/core-concepts/plugins.md with TypeScript-focused examples linking to test cases
• [ ] Add CI step to run 'pnpm run test:dts' on PR changes to src/ or tests/ in packages/pinia

• Add missing i18n documentation for the German (de) or French (fr) language config in packages/docs/.vitepress/config/ (en.ts and zh.ts exist but de.ts is missing); requires copying the navigation structure and translating nav labels
• Create a TypeScript-specific testing guide under packages/docs/cookbook/ showing how to type-safely test Pinia stores with Vitest and asserting store state changes; currently no dedicated test patterns doc exists
• Add JSDoc comments to public APIs in packages/pinia/src/store.ts and packages/pinia/src/createPinia.ts to improve IDE autocomplete hints; many core functions lack inline documentation for better DX

Pinia demonstrates a reasonable security posture as a Vue state management library. The project has a SECURITY.md policy in place and uses modern tooling (TypeScript, monorepo structure with pnpm). However, several concerns require attention: (1) The SECURITY.md file is incomplete and truncated, leaving security reporting guidance ambiguous; (2) The package.json snapshot is incomplete, preventing full dependency vulnerability assessment; (3) No visible evidence of automated dependency scanning in the provided documentation; (4) GitHub Actions workflows referenced but not reviewed for security configuration. The project should prioritize completing security documentation, implementing automated vulnerability scanning, and ensuring all workflow files follow GitHub Actions security best practices. Overall, this is a well-maintained official Vue ecosystem library with reasonable security practices, but documentation and configuration visibility gaps prevent a higher score.

• High · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file is truncated and incomplete. The vulnerability reporting section ends abruptly mid-sentence, suggesting incomplete security guidance documentation. This could leave users uncertain about proper security reporting procedures. Fix: Complete the SECURITY.md file with full security reporting guidelines, expected response times, and disclosure policy details.
• Medium · Outdated Dependencies in Package.json — package.json. Several dependencies use older versions that may contain known vulnerabilities: '@types/node@^24.10.0' is very recent (potential compatibility issues), '@vitest/coverage-v8@^4.0.18' and '@vitest/ui@^4.0.18' are pinned to older v4 releases. The package.json snippet is truncated, making full assessment impossible. Fix: Run 'npm audit' or 'pnpm audit' to identify vulnerable dependencies. Update to the latest patch versions of all dependencies. Consider using automated dependency scanning in CI/CD pipeline.
• Medium · Incomplete Dependency List in Package.json — package.json. The devDependencies list in package.json is truncated and incomplete (ends at 'lodash.kebabcase' without version). This makes it impossible to perform a complete security audit of all dependencies. Fix: Ensure the full package.json file is provided. Regularly audit all dependencies using tools like Snyk or npm audit.
• Low · Missing .npmrc Security Configuration Details — .npmrc. The .npmrc file is referenced in the file structure but its contents are not provided. This file may contain critical npm security settings or authentication tokens. Fix: Verify that .npmrc does not contain hardcoded credentials. Use npm token management and ensure proper .gitignore rules prevent credential leakage. Review npm security best practices.
• Low · Monorepo Workspace Configuration — package.json - 'workspaces' field. The project uses pnpm workspaces with multiple packages. Complex dependency management in monorepos can introduce transitive vulnerability chains if not properly monitored. Fix: Implement workspace-level dependency scanning. Use 'pnpm audit --recursive' to check all workspace dependencies. Consider implementing automated dependency checking in CI/CD workflows as shown in .github/workflows/ci.yml.
• Low · GitHub Workflow Security — .github/workflows/. Release workflow (.github/workflows/release-tag.yml) and CI workflow (ci.yml) are referenced but contents not provided. These workflows may have permission issues or insecure secret handling practices. Fix: Review all GitHub Actions workflows for: 1) Minimal required permissions using 'permissions' field, 2) Secret handling best practices, 3) Third-party action pinning, 4) No hardcoded credentials.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/vuejs/pinia shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live vuejs/pinia repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/vuejs/pinia.

What it runs against: a local clone of vuejs/pinia — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in vuejs/pinia | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch v4 exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 39 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of vuejs/pinia. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/vuejs/pinia.git
#   cd pinia
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of vuejs/pinia and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "vuejs/pinia(\\.git)?\\b" \\
  && ok "origin remote is vuejs/pinia" \\
  || miss "origin remote is not vuejs/pinia (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify v4 >/dev/null 2>&1 \\
  && ok "default branch v4 exists" \\
  || miss "default branch v4 no longer exists"

# 4. Critical files exist
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"
test -f "packages/pinia" \\
  && ok "packages/pinia" \\
  || miss "missing critical file: packages/pinia"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f "packages/docs/introduction.md" \\
  && ok "packages/docs/introduction.md" \\
  || miss "missing critical file: packages/docs/introduction.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 39 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~9d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/vuejs/pinia"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.