The Pinia ecosystem keeps moving. This episode covers the Pinia v4.x release with type improvements and Vue 3.5+ compatibility, @pinia/nuxt 1.x integration, and the 2026 ecosystem: @pinia/testing 2.x and Pinia Colada, now stable for async server state.

Technology never stops, and neither does Pinia. Heading into its latest release, the Pinia team keeps refining types, compatibility with the latest Vue, and its supporting ecosystem. Episode 20 maps the state of Pinia v4 and the 2026 ecosystem.
Episode 20 covers the latest stable features: what changed in Pinia v4.x, Vue 3.5+ compatibility, and the position of supporting libraries like @pinia/nuxt, @pinia/testing, and Pinia Colada.
Pinia v4.0.x was released in July 2026 as a major update bringing comprehensive improvements:
One of the most noticeable improvements is type inference on Setup stores. Look at the example of state and getter in a single definition:
export const useThemeStore = defineStore('theme', () => {
const mode = ref<'light' | 'dark'>('light')
const isDark = computed(() => mode.value === 'dark')
return { mode, isDark }
})In v4, ref<'light' | 'dark'> is inferred automatically by TypeScript, so you don't need to write the generic defineStore<string, ...> explicitly. As a result, store.mode and store.isDark are correctly typed in components — the editor gives autocomplete and errors from the moment you write, not at runtime. This improvement is felt most in projects that write many Setup stores.
The key point: Pinia's core API — defineStore, createPinia, storeToRefs — stays stable. Upgrading to v4 doesn't require rewriting the stores you learned in episodes 0-19.
npm view pinia version
npm view @pinia/nuxt versionnpm view pinia version and npm view @pinia/nuxt version show the latest versions in the registry. This verification is important before upgrading so the documentation you read matches the version.
Pinia v4 is designed on top of Vue 3.5+, which brings reactivity performance improvements and better type support. What you need to know:
ref and reactive work as usual — no store syntax changes.Because backwards compatibility is maintained, projects on Vue 3.4 can generally upgrade without breaking — but the officially recommended combination is Vue 3.5+ with Pinia v4.
Migration is generally as easy as changing the version in package.json and running npm i. There's no rename command like when Vue 2 moved to Vue 3; the only areas to watch are those related to types:
// v3 and v4 accept this code without changes
export const useUserStore = defineStore('user', {
state: () => ({
profile: null as Profile | null,
}),
getters: {
isLoggedIn: (state) => state.profile !== null,
},
})null as Profile | null still works in v4 thanks to better generic inference. In older releases, generic combinations like defineStore<string, State, Getters, Actions> sometimes forced writing all four parameters explicitly; in v4 those parameters are inferred automatically, so store code feels more concise.
Recommended migration steps:
bun run typecheck and resolve all errors.@pinia/testing.If all tests are green and there are no type errors, the migration is practically done. The remaining time is best spent exploring type improvements that allow simplifying store code.
Three supporting libraries are now stable and have become standard:
createTestingPinia (episode 17).pinia: 4.0.2
@pinia/nuxt: 1.0.1
@pinia/testing: 2.0.xAll three work together: Nuxt for SSR, testing for quality, and Colada for server state. This is the complete Pinia stack in 2026.
Info
Always verify the latest versions via npm view and the official GitHub changelog before a major upgrade. New minor releases often bring improvements without API changes.
Episode 20 maps the current state of Pinia. You now know what changed in Pinia v4.x, why Vue 3.5+ is the recommended pairing, and the position of the three supporting libraries that are now stable: @pinia/nuxt, @pinia/testing, and Pinia Colada.
Key takeaways:
npm view before upgrading.In the next episode, episode 21, we'll discuss production-ready architecture — store architecture for team scale, naming and documentation conventions, using Vue Query or Colada for server state, and production quality: type-check, lint, test coverage, monitoring, and bundle size.