feat: skip attaching the launcher when its embedded and update tests

[jaissica12]

Summary

• Skip script tag creation when launcher.js is embedded. If window.Rokt.createLauncher already exists, directly call attachLauncher() instead of fetching launcher.js via a new script tag
• WILL CHANGE THE TARGET BRANCH WHEN MAIN AND DEVELOPMENT ARE IN SYNC

Testing Plan

• Tested through unit tests

[Copilot]

Pull request overview

This pull request optimizes the Rokt launcher initialization by detecting when the launcher.js is already embedded on the page and skipping redundant script tag creation. When window.Rokt.createLauncher exists, the code now calls attachLauncher() directly instead of fetching launcher.js via a new script tag, unless the launcher has already been initialized.

Changes:

• Modified initialization logic to check for embedded launcher before creating script tags
• Removed misleading console warning when Rokt is already present
• Added test coverage for embedded launcher scenarios

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Rokt-Kit.js	Updated initForwarder to check if launcher is embedded and call attachLauncher directly, eliminating redundant script loading
test/src/tests.js	Updated existing test to force script loading path and added new tests to verify embedded launcher behavior

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When window.Rokt.currentLauncher already exists, the code skips calling attachLauncher(), which means self.launcher is never set and self.isInitialized remains false (unless this is a re-initialization of the same forwarder instance).

Consider adding a test case that verifies the forwarder's functionality after init() is called when currentLauncher already exists. Specifically, check whether isKitReady() returns true and whether core forwarder methods like selectPlacements() and hashAttributes() work correctly.

If the forwarder should be functional in this scenario, the code may need to attach to the existing launcher instance rather than skipping initialization entirely.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

For better test isolation and consistency, consider explicitly initializing the createLauncherCalled flag in the new mParticle.Rokt object. While this test doesn't assert on createLauncherCalled, adding it would match the pattern used in beforeEach (line 542) and prevent potential issues if future tests rely on this flag's state. Example: createLauncherCalled: false

Suggested change

	filters: savedRokt.filters,
	filters: savedRokt.filters,
	createLauncherCalled: false,

[alexs-mparticle]

Question: How does the launcher get the accountId and the launcherOptions in this flow?

[jaissica12]

In this else block, reusing an existing launcher that was already created with accountId and launcherOptions by a previous initialization. The launcher object stores its configuration internally, so we just attach our forwarder instance to it via initRoktLauncher().

Below is my understanding:

• First init: window.Rokt.currentLauncher is undefined → attachLauncher(accountId, launcherOptions) creates a new launcher via createLauncher({accountId, ...launcherOptions}) → launcher stores this config internally

• Subsequent (this else block): currentLauncher already exists → we skip creating a new one and just call initRoktLauncher(existingLauncher) to attach the current forwarder instance to it

• The accountId and launcherOptions should already be baked into the existing launcher from the first init. Since mParticle workspaces have one Rokt kit configuration, all forwarder instances would be sharing the same accountId.