Release 1232.0.0

[gauthierpetetin]

Explanation

Summary

Publish @metamask/analytics-controller@2.1.0 so clients can opt into journey-scoped event fragments from #10055.

Problem

Clients that track multi-step user journeys (signature requests, transaction confirmations, and similar flows) must re-derive the same analytics properties at every step, or build ad hoc state to carry them forward. There is no shared controller primitive for accumulating properties across a journey and optionally closing it with a success or failure event.

Solution

• @metamask/analytics-controller@2.1.0 (minor): add optional event fragments, disabled by default via isEventFragmentsEnabled
  • Funnel shape: declare initialEvent, successEvent, and/or failureEvent, then call finalizeEventFragment
  • Property-bag shape: declare no event names and read accumulated properties back with getEventFragmentById when emitting a custom event
  • Fragment methods respect the same consent gate as trackEvent, return read-only copies from createEventFragment / getEventFragmentById, and discard stale non-persistent or expired persisted fragments on init

Workspace dependents bump their @metamask/analytics-controller range to ^2.1.0 but are not published in this release:

• @metamask/network-controller
• @metamask/wallet-cli

Risk

No breaking API changes. Event fragments are disabled by default, so existing consumers keep current behavior until they opt in with isEventFragmentsEnabled.

@metamask/analytics-controller@2.1.0

Added

• Add optional event fragments to AnalyticsController (disabled by default via isEventFragmentsEnabled), letting clients accumulate analytics properties across a user journey and optionally emit an initial, success, or failure event for it (#10055)

Changed

• Bump @metamask/utils from ^11.11.0 to ^11.12.0 (#10076)

References

• Related to feat(analytics-controller): add optional event fragments for journey-scoped properties #10055

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Made with Cursor

[metamask-ci]

✅ Changelogs updated and pushed.

[NicolasMassart]

Looks good to me.