pinia

Reproduction https://stackblitz.com/edit/github-jm6ehxba?file=package.json Steps to reproduce the bug Hi 👋 After updating to @pinia/nuxt 1.0 from version 0.11 and also from pinia 3 to 4 I saw that started to fail on pre-rendered pages. The reproduction repo has: Nuxt 4.5 Pinia 4 + @pinia/nuxt 1.0 Nitro pre-rendering on "/" page To reproduce 1. Run with + 2. Run , it fails with access to undefined state 3. Downgrade to + 4. Run to see the build passing fine If you remove the prerendering from the route on everything works like in Expected behavior While running on Pinia 3, Nitro pre-rendering worked fine on Build, this is expected on Pinia 4 too Actual behavior While building a pre-rendered route using Pinia 4 the build process fails with a mention on: Additional information _No response_

Reproduction https://github.com/andreyshivas/pinia4-nitro-ssr-repro Steps to reproduce the bug Minimal Nuxt 4 app — is the only module and no store is defined, since runs on every request regardless. Expected behavior works in a Node SSR server regardless of , as it did on Pinia 3. Actual behavior Every SSR render fails once : Pinia 4 publishes only a bundler build. contains: and the exports map is a single unconditional entry: still references the Vue compile-time flag (5 occurrences). Nitro externalises pinia for the Node server build, so the file is copied to and loaded as-is — nothing ever substitutes the flag. Pinia 3 shipped with the flags already substituted, so the same app works on 3.0.4. This looks like an unintended packaging regression in 4. Additional information Why it only appears in production. The reference sits behind a short-circuit: Any other than makes the left operand true, so the missing global is never evaluated. A local run looks perfectly healthy and the app only fails once deployed. The reported error is misleading. Nuxt catches the failing plugin chain, hands the error to , sets and carries on rendering. 's hook then runs against a that was never provided, and only that secondary error reaches the logs: It mentions neither , nor , nor Pinia at all. Recovering the real cause required registering a custom hook. Results. Workaround. Force Pinia through the bundler so the flag gets defined: Possible fixes. Ship a Node production build again behind conditional exports, as 3.x did. Or guard the reference — — so an unsubstituted flag degrades instead of throwing. Environment. pinia 4.0.2, @pinia/nuxt 1.0.1, nuxt 4.5.2, vue 3.5.41, Node 24.19.0 (also reproduced on the Linux deploy that surfaced it). Verified against the published npm tarball for — same listing and the same 5 references to the flag, so this is not an install artefact.

What problem is this solving V4.0.2 version Object. hasOwn is not compatible with Android 11 and below versions Proposed solution Suggest using Object. hasOwnProperty for compatibility Describe alternatives you've considered _No response_