feat(rokt): expose terminate on the window.mParticle.Rokt interface

[jamesnrokt]

Summary

Adds RoktManager.terminate(), exposing window.mParticle.Rokt.terminate() as a supported teardown path for partners who cannot simply destroy the container element — SPA route changes and confirmation pages in particular.

Today partners reach for the undocumented window.Rokt.currentLauncher?.terminate(). This routes the same call through the documented interface.

Pairs with mparticle-integrations/mparticle-javascript-integration-rokt#122, which adds the terminate() the manager delegates to. That PR should merge and release first — until a kit carrying it is on the page, this method logs that the attached kit version does not support terminate.

Changes

• RoktManager.terminate(): Promise<void> — delegates to this.kit.terminate(), which forwards to the Rokt launcher.
• IRoktKit.terminate added as optional, guarded at the call site with isFunction. The Rokt Kit releases on its own cadence, so a kit published before this change genuinely will not implement it — version skew is real rather than theoretical.

IRoktLauncher is untouched: the manager only ever calls through the kit, and the kit owns the launcher-facing type.

Behaviour

State	Result
Kit + launcher attached	awaits kit.terminate()
Nothing attached	Resolves as a no-op, logs verbose
Kit attached, no launcher	Resolves as a no-op
Kit predates terminate	Resolves, logs error
kit.terminate() rejects	Resolves, logs error

terminate() never rejects — teardown should not be something callers have to defend against.

A pre-ready call is not queued

Every other proxied method uses deferredCall when the kit isn't ready. terminate deliberately does not. Replaying a teardown against a launcher created later would silently tear down placements the caller never asked to remove; with no launcher there is nothing to terminate, so the call resolves as a no-op instead. This asymmetry is called out in the method's doc comment and pinned by tests.

Also fixes a latent snippet bug

terminate is already in the snippet's roktMethods stub list (snippet.js), so a snippet-loaded page could queue Rokt.terminate() before init. At flush time processPreloadedItem hit an undefined method, threw, and processReadyQueue logged Unable to compute proper mParticle function. That path now dispatches correctly.

⚠️ getVersion has the same latent gap — it is in the snippet stub list but has no RoktManager implementation. Left out of scope here; happy to add it in a follow-up if wanted.

Not included

kits/rokt/ in this repo is a stale vendored snapshot of the Rokt kit (missing storage.ts, utils.ts, pageViewStorage.ts) and is not loaded by any build or test target, so it was intentionally left untouched. The live kit change is in the companion PR.

Testing

• npm run lint — pass
• npm run test:jest — 632/632 across 26 suites
• Karma (ChromeHeadless) — 1087/1087

7 new #terminate cases in test/jest/roktManager.spec.ts cover each row of the behaviour table above, plus a case asserting the manager stays ready so repeat calls keep reaching the kit. The suite fails to compile against development without the source change.

Note for reviewers running locally: Karma's default config includes FirefoxHeadless and aborts the whole run if Firefox isn't installed. Use npx karma start test/karma.config.js --browsers ChromeHeadless.

🤖 Generated with Claude Code

[cursor]

PR Summary

Low Risk
Additive public API with defensive error handling; behavior is isolated to Rokt teardown and covered by new unit tests.

Overview
Adds window.mParticle.Rokt.terminate() as the documented way to tear down the Rokt launcher and placements (e.g. SPA navigations), delegating to optional kit.terminate() when the attached Rokt kit supports it.

RoktManager.terminate() always resolves (never rejects): it no-ops with verbose logging when the manager is not ready or there is no launcher, logs an error for older kits without terminate, and swallows kit teardown failures after logging. Unlike other proxied Rokt APIs, pre-ready calls are not queued so a late replay cannot tear down placements the host did not intend to remove.

IRoktKit.terminate is optional to tolerate kit/SDK version skew. Seven Jest cases cover delegation, timing, no-op paths, unsupported kit, rejection handling, and repeat calls while staying ready.

^{Reviewed by Cursor Bugbot for commit b41570f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmi22186]

This LGTM. @mattbodle's comment over at mparticle-integrations/mparticle-javascript-integration-rokt#122 shouldn't affect the implementation here, though I'm not 100% clear on the use case of creating a new launcher right after terminating. That seems unlkely?

Edit: Oh I see, for SPAs, so a customer may go back and make another purchase, right?