Package-name migration
leadmaps public packages now use the @leadmaps npm scope. Existing
@syntarie installations keep working during a 60-day compatibility window,
so you can migrate in a normal release rather than as an emergency.
The stable migration release shipped on July 31, 2026. Compatibility support
for the final @syntarie releases ends on September 29, 2026. Published
versions remain installable after that date.
Package mapping
Section titled “Package mapping”| Historical package | Final compatible version | Canonical package | Stable version |
|---|---|---|---|
@syntarie/tracking | 0.14.3 | @leadmaps/tracking | 0.14.3 |
@syntarie/tracking-node | 0.0.4 | @leadmaps/tracking-node | 0.0.4 |
@syntarie/shared | 1.2.0 | @leadmaps/shared | 2.0.1 |
@syntarie/mcp | 0.3.1 | @leadmaps/mcp | 0.3.1 |
The browser SDK, Node SDK, and MCP package keep their existing public API and
version line. @leadmaps/shared starts at 2.0.0 because it intentionally offers
a smaller customer contract. Version 2.0.1 adds the public consent-banner
configuration contract.
Browser SDK
Section titled “Browser SDK”pnpm remove @syntarie/trackingpnpm add @leadmaps/trackingReplace the scope in imports:
import { init, track } from '@syntarie/tracking';import { init, track } from '@leadmaps/tracking';Subpaths keep the same name, including /replay, /experience,
/consent-banner, /forms, /feature-flags, and /ecommerce.
If you load the SDK through a CDN, change the package name there too:
https://esm.sh/@syntarie/trackinghttps://esm.sh/@leadmaps/trackingNode SDK and MCP
Section titled “Node SDK and MCP”Use the same package replacement for your server application or MCP client:
pnpm remove @syntarie/tracking-node @syntarie/mcppnpm add @leadmaps/tracking-node @leadmaps/mcpMCP environment variables and tool names do not change.
Shared contracts
Section titled “Shared contracts”@leadmaps/shared contains the supported customer-facing contracts for:
- Events and the event JSON schema.
- Brand, attribution, and identity types.
- Feature-flag types and evaluation.
- Insight and anomaly types.
- Experience analytics types.
- Consent-banner configuration types.
- Tracking-plan parsing and schema.
- License verification.
Historical subpaths for product billing policy, plan enforcement, cohort execution, lead-pipeline runtime, site-liveness policy, and storage gates are not part of the canonical public package. If your application imported one of those modules, keep the historical package during the compatibility window and move that behavior to the corresponding leadmaps API.
Compatibility window
Section titled “Compatibility window”The final historical releases are supported through September 29, 2026. During
that window, critical and security fixes are published under both scopes. New
installation instructions and later feature releases use @leadmaps.
After the window, the historical package names are deprecated rather than unpublished, so existing lockfiles remain reproducible.
No browser console warning is added for the scope migration.