@mushi-mushi/* 0.x → 1.0

Why we keep this page on the hub

Customers ask about the upgrade path before they install — knowing there is a documented upgrade rail is a buying signal. So we ship the rail empty rather than have it appear out of nowhere on 1.0 release day.

When 1.0 ships, this page will list:

• The exact breaking changes per package (web, react, vue, svelte, angular, react-native, capacitor, ios, android).
• A codemod (npx mushi-mushi upgrade@latest) for the mechanical rewrites.
• A checklist for the things the codemod can’t reach (CSP rules, build-time env vars, your team’s runbooks).

What 1.0 will / won’t break (current intent)

We expect 1.0 to not break:

• The Mushi.init({ projectId, apiKey }) shape — this is the public contract every customer wires.
• The Mushi.report({ description, ... }) shape.
• The <MushiProvider> component in React, Vue, Svelte, RN.
• Wire-format API endpoints (/v1/reports, /v1/admin/*).
• The MCP server protocol.

We expect 1.0 to possibly break:

• Internal capture types (currently exported via @mushi-mushi/core), if you reach into them. Most customers don’t.
• The legacy Mushi.captureException shim — likely deprecated in favour of Mushi.report({ description: error.message }).
• The bundled-CSS export path — likely renamed for clearer intent.
• Default privacy-redaction list — likely expanded.

If you build only against the documented public API (everything under /sdks/* in these docs), the 1.0 upgrade should be a single bump in package.json.

Migration checklist (placeholder)

Per-package upgrade tracker

When 1.0 ships, this section will be a table:

References

• Mushi Mushi GitHub repo  (per-package CHANGELOG.md)
• /sdks/* reference — the public API surface 1.0 commits to