fix: use ph persistence instead of localStorage on surveys

[alexedwardjones]

Problem

A fix went in for local storage usage in surveys but it was reverted due to a bug.

My understanding is that the bug was related to persistence.isDisabled is not a function. This PR reapplies the fix with a few extra checks around the isDisabled function and falls back to _disabled if necessary.

Changes

• Reapplied the persistence migration for surveys (using the shared persistence layer instead of touching localStorage directly).
• Guarded the persistence check with isFunction and a _disabled fallback so we never call a missing isDisabled.
• Added a regression test (surveys-persistence.test.ts) that simulates a “legacy” instance without isDisabled to make sure we don’t regress again.

Release info Sub-libraries affected

Libraries affected

• All of them
• posthog-js (web)
• posthog-js-lite (web lite)
• posthog-node
• posthog-react-native
• @posthog/react
• @posthog/ai
• @posthog/nextjs-config
• @posthog/nuxt

Checklist

• Tests for new code (runs for packages/browser/src/tests/extensions/surveys-persistence.test.ts; rest of the suite currently fails earlier because other packages are missing dev deps, so reviewers may want to re-run once the workspace installs)
• Accounted for cross-platform impact (surveys only touch the browser SDK)
• Backwards compatibility (still falls back to localStorage when persistence is disabled or unavailable)
• Bundle size considerations (only adds a tiny helper import; no new runtime dependencies)

If releasing new changes

• Ran pnpm changeset (see .changeset/giant-lamps-cover.md or whatever file you created)
• [] Added the release label once you’re ready to publish

[vercel]

@alexedwardjones is attempting to deploy a commit to the PostHog Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

_{12 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

logic: props is an object (Record<string, Property>), not an array. Checking .length === 0 will always evaluate to undefined === 0 (false), so this early return never works when props is empty. Use Object.keys(this._instance.persistence.props).length === 0 instead.

Suggested change

	if (!this._instance.persistence?.props || this._instance.persistence?.props.length === 0) {
	if (!this._instance.persistence?.props || Object.keys(this._instance.persistence.props).length === 0) {

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/browser/src/posthog-surveys.ts
Line: 64:64

Comment:
**logic:** `props` is an object (Record<string, Property>), not an array. Checking `.length === 0` will always evaluate to `undefined === 0` (false), so this early return never works when props is empty. Use `Object.keys(this._instance.persistence.props).length === 0` instead.

```suggestion
        if (!this._instance.persistence?.props || Object.keys(this._instance.persistence.props).length === 0) {
```

How can I resolve this? If you propose a fix, please make it concise.

[lucasheriques]

hey Alex! thanks for getting this back on. I'll review and test today and get back to you ASAP

[posthog-bot]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.