[russell-loube-mixpanel]

What

Adds a Get All Flag Assignments section to the JavaScript (Web) feature flags page. get_all_variants() and get_all_variants_sync() have shipped in mixpanel-js since v2.79.0 and are in the public typings (FlagsManager), but appeared nowhere on the page.

Docs-only. No SDK changes, and the Swift page is untouched.

Structure

Mirrors the Swift page's equivalent section — same H3 placement under Flag Evaluation, same Synchronous/Asynchronous split — but the documented behavior is derived from src/flags/index.js, not from the Swift copy.

The JS-specific details it covers

• Neither method fires exposure tracking. trackFeatureCheck has exactly one call site in the SDK (getVariantSync, src/flags/index.js:580); neither all-variants method reaches it, so no $experiment_started is sent. Pinned by a test at tests/unit/flags.js:1495. This is the main reason people reach for these methods, so it leads the section.
• The return value is a Map, not a plain object. Swift's dictionary idiom doesn't translate and Object.keys(variants) silently yields []. Examples use .forEach((variant, key) => ...) and for...of.
• No arguments and no fallback parameter, unlike get_variant — an unassigned flag is simply absent rather than falling back.
• Per-policy async resolution (networkOnly / networkFirst / persistenceUntilNetworkSuccess), drawn from the tests at tests/unit/flags.js:1417, :1423, and :1436. The async method always resolves and never rejects.
• One place JS genuinely diverges from Swift: the Swift docs say the async method "will attempt to fetch" if flags aren't loaded. JS does not — getAllVariants checks this.fetchPromise and returns an empty Map if nothing is in flight; it never calls loadFlags. Documented as the JS behavior.
• Both return the SDK's internal Map by reference, not a copy (tests/unit/flags.js:1492 asserts strict identity). Mutating the result corrupts SDK flag state, so that gets a <Warning>.

Version claim

v2.79.0, established from the SDK repo rather than assumed. Both methods and their snake_case aliases landed together in c3a3e83 (mixpanel/mixpanel-js#433, "Implement flags variant persistence"); earliest tag containing it is v2.79.0; CHANGELOG 2.79.0 (14 May 2026) describes the persistence work; npm confirms 2.79.0 published 2026-05-14. Consistent with the version note already on the page's Flag Persistence section.

Left out, on purpose

get_variant_sync, are_flags_ready, load_flags, and when_ready also ship undocumented on this page. Kept out to keep this diff reviewable — happy to follow up in a separate PR.

Reviewer note

The ## Flag Evaluation preamble still says "This action triggers tracking an exposure event," which the new subsection contradicts locally. I left it alone because the Swift page has the same tension and resolves it in the subsection rather than the parent heading. Easy to soften if you'd rather.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
mixpanel-docs	🟢 Ready	View Preview	Oct 28, 2026, 5:48 PM

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge; no new actionable issue was found.

_{Reviews (10) · Last reviewed commit: "Merge branch 'main' into docs/js-flags-g..." · Reviewed by Greptile}