chore: migrate toolchain to TypeScript 5.5, Vite, Vitest, and ESLint v9 by mattbodle · Pull Request #84 · mparticle-integrations/mparticle-javascript-integration-rokt

mattbodle · 2026-04-02T02:12:54Z

Summary

Migrates source from src/Rokt-Kit.js (ES5) to src/Rokt-Kit.ts (TypeScript 5.5, strict mode, class-based)
Replaces Rollup v1 with Vite (library mode, explicit target: 'es2020') producing IIFE + CJS bundles + .d.ts type declarations
Replaces the legacy manual Mocha HTML runner (test/index.html) with Vitest + jsdom (158 tests, headless — no automated real-browser testing existed before)
Replaces ESLint v7 .eslintrc with ESLint v9 flat config (eslint.config.mjs)
Updates Prettier to 120-char width, single quotes, trailing commas
Bumps .nvmrc to Node 24

Browser baseline: The emitted IIFE targets ES2020 (const, let, class, ??, ?.). This is the first explicit browser target — no baseline existed before. Real-browser smoke testing can be added in a follow-up if needed.

Test plan

npm run lint — zero errors
npm run build — produces dist/Rokt-Kit.iife.js, dist/Rokt-Kit.common.js, dist/Rokt-Kit.d.ts
npm run test — 158/158 tests pass in Vitest/jsdom

🤖 Generated with Claude Code

Replaces the 2019-era ES5/Rollup/Karma/Mocha/Chai stack with a modern toolchain aligned with the internal sdk-web repo: - Source: src/Rokt-Kit.js → src/Rokt-Kit.ts (class-based, strict mode) - Build: Rollup v1 → Vite (IIFE + CJS + .d.ts via vite-plugin-dts) - Tests: Karma + Mocha/Chai → Vitest + jsdom (158 tests passing) - Lint: ESLint v7 (.eslintrc) → ESLint v9 flat config (eslint.config.mjs) - Prettier: updated to 120-char width, single quotes, trailing commas - Node: .nvmrc bumped to 24 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

mattbodle · 2026-04-02T02:32:06Z

Background: this PR replaces both the build tool and the test runner for a browser SDK. The description lists the mechanical changes, but it does not say whether browser support changes or what replaces the old real-browser verification.

Please add that context explicitly. Missing in this PR description: the supported browser baseline after the Vite build, whether dropping Chrome and Firefox coverage is intentional, and whether a browser-level smoke test is coming in a follow-up PR.

-Codex

mattbodle · 2026-04-02T02:32:27Z

vite.config.ts

+import { resolve } from 'path';
+
+export default defineConfig({
+  build: {


Background: this build now ships a materially different browser target from the current release. The emitted dist/Rokt-Kit.iife.js contains const, let, class, arrow functions and ??, while the previous bundle was ES5-style. For a kit that is injected into merchant pages, that is a breaking runtime change unless we have explicitly raised the browser baseline.

Please set an explicit supported build target and verify the published IIFE against it before merging.

-Codex

Done — added target: 'es2020' to vite.config.ts. The IIFE now has an explicit browser baseline. Added a note to the PR description clarifying this is the first explicit target (no baseline existed before).

mattbodle · 2026-04-02T02:32:27Z

package.json

+    "build": "vite build",
+    "lint": "eslint \"src/**/*.ts\" \"test/**/*.ts\"",
+    "lint:fix": "eslint \"src/**/*.ts\" \"test/**/*.ts\" --fix",
+    "test": "vitest run",


Background: after this change the executed suite is test/src/**/*.spec.ts, but the old Karma harness still stays in-tree: test/src/tests.js, test/index.html, test/config.js and test/lib/mockhttprequest.js. That leaves a second, dead test path in the repo and adds maintenance cost to a migration PR that is supposed to simplify the toolchain.

Delete the legacy harness in the same PR, or call out clearly why it needs to stay.

-Codex

Done — deleted test/src/tests.js, test/index.html, test/config.js, and test/lib/mockhttprequest.js in commit 7d03487.

mattbodle · 2026-04-02T02:32:27Z

src/Rokt-Kit.ts

+
+    const selection = this.launcher!.selectPlacements(selectPlacementsOptions);
+
+    // After selection resolves, sync the Rokt session ID back to mParticle


Background: this works, but the same side-effect is repeated in four branches, which makes the success and failure flow harder to scan than it needs to be. Normalising the result to one promise and logging once in a terminal branch would read more cleanly.

For example:

const logSelection = () => this.logSelectPlacementsEvent(selectPlacementsAttributes); void Promise.resolve(selection) .then((sel) => sel?.context?.sessionId?.then((sessionId) => this.setRoktSessionId(sessionId))) .catch(() => undefined) .finally(logSelection);

That keeps the monadic flow in one place and makes the side-effects explicit.

-Codex

Done — adopted the single Promise.resolve() chain with .finally() for the log, as suggested. Fixed in 7d03487.

- Set explicit build target (es2020) in vite.config.ts - Refactor selectPlacements to use a single functional promise chain - Delete legacy Mocha HTML test harness (tests.js, index.html, config.js, mockhttprequest.js) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

mattbodle · 2026-04-02T02:45:08Z

Re: @mattbodle's comment: The old test harness was a manual Mocha HTML page (test/index.html) — no automated browser testing existed before, so no Chrome/Firefox coverage is being dropped. The PR description has been updated to reflect this and to call out that es2020 is the first explicit browser target.

rmi22186 · 2026-04-02T17:49:10Z

.claude/skills/verify/skill.md


-> `npm run test` runs `npm run build && npm run build:test && karma start test/karma.config.js` — it builds the source, builds the test bundle, and runs Karma with Mocha/Chai in Chrome and Firefox.
+> `npm run test` runs Vitest in headless jsdom mode.
+> `npm run build` runs Vite and produces IIFE and CommonJS bundles + TypeScript type declarations.


nit - we should add an esm module as well. it was missing from like 1/2 our npm packages and we started to fix that in the mono repo

rmi22186 · 2026-04-03T00:18:26Z

src/Rokt-Kit.ts

+function mergeObjects(...args: Record<string, unknown>[]): Record<string, unknown> {
+  const resObj: Record<string, unknown> = {};
+  for (const obj of args) {
+    if (obj && typeof obj === 'object') {
+      const keys = Object.keys(obj);
+      for (const key of keys) {
+        resObj[key] = obj[key];
+      }
+    }
+  }
+  return resObj;
+}


Is it intentional to leave this in here to ensure that we are doing a strict js --> ts as opposed to starting to incorporate ts features, like spread operators which would would remove the need for this method?

rmi22186 · 2026-04-03T00:40:34Z

src/Rokt-Kit.ts

+          window.Rokt.__event_stream__!(this.enrichEvent(queuedEvents[i]));
+        }
+      }
+      window.Rokt.__event_stream__!(this.enrichEvent(event));


Both these are inside the check for it on line 566, so no ! needed

Suggested change

window.Rokt.__event_stream__!(this.enrichEvent(queuedEvents[i]));

}

}

window.Rokt.__event_stream__!(this.enrichEvent(event));

window.Rokt.__event_stream__(this.enrichEvent(queuedEvents[i]));

}

}

window.Rokt.__event_stream__(this.enrichEvent(event));

rmi22186 · 2026-04-03T00:51:13Z

src/Rokt-Kit.ts

+        generateLauncherScript: generateLauncherScript,
+        extractRoktExtensions: extractRoktExtensions,
+        hashEventMessage: hashEventMessage,
+        parseSettingsString: parseSettingsString,
+        generateMappedEventLookup: generateMappedEventLookup,
+        generateMappedEventAttributeLookup: generateMappedEventAttributeLookup,
+        sendAdBlockMeasurementSignals: sendAdBlockMeasurementSignals,
+        createAutoRemovedIframe: createAutoRemovedIframe,
+        djb2: djb2,
+        setAllowedOriginHashes: (hashes: number[]) => {
+          RoktKit._allowedOriginHashes = hashes;
+        },


Future improvement - we may be able to simply export these individual methods and not need this annoying helper anymore

rmi22186 · 2026-04-03T00:55:40Z

src/Rokt-Kit.ts

+      return;
+    }
+
+    const hashedEvent = hashEventMessage(event.EventDataType ?? 0, event.EventCategory ?? 0, event.EventName ?? '');


EventDataType and EventCategory will never be falsey, so we shoudl remove the ?? 0 afterwards and update the hashEventMessage definition to make them required. having a 0 would likely mess up the hash

rmi22186 · 2026-04-03T01:03:06Z

src/Rokt-Kit.ts

+    void Promise.resolve(selection)
+      .then((sel) => sel?.context?.sessionId?.then((sessionId) => this.setRoktSessionId(sessionId)))
+      .catch(() => undefined)
+      .finally(logSelection);


❤️ huge improvement over this monstrosity

alexs-mparticle · 2026-04-03T02:19:51Z

src/Rokt-Kit.ts

+// Types
+// ============================================================
+
+interface KitSettings {


Nit: These should be RoktKitSettings as I can see a case in the future where we have a more generic KitSettings interface.

alexs-mparticle · 2026-04-03T02:20:57Z

src/Rokt-Kit.ts

+  getUserIdentities?: () => { userIdentities: Record<string, string> };
+}
+
+interface KitFilters {


Can this be imported from the core SDK type definitions?

alexs-mparticle · 2026-04-03T02:21:06Z

src/Rokt-Kit.ts

+  filteredUser?: FilteredUser | null;
+}
+
+interface RoktManager {


Can this be imported from the core SDK type definitions?

alexs-mparticle · 2026-04-03T02:21:57Z

src/Rokt-Kit.ts

+// Types
+// ============================================================
+
+interface KitSettings {


At this point, can we consider breaking up this single file into smaller modules?

alexs-mparticle · 2026-04-03T02:24:16Z

src/Rokt-Kit.ts

+
+    return {
+      EventName: eventName,
+      EventDataType: 14, // MessageType.Profile


Should we just use the type enums?

alexs-mparticle · 2026-04-03T02:30:11Z

package.json

+    "test": "vitest run",
+    "test:watch": "vitest",
+    "test:coverage": "vitest run --coverage",
+    "test:ui": "vitest --ui"


Why do we need a ui test?

mattbodle commented Apr 2, 2026

View reviewed changes

rmi22186 reviewed Apr 2, 2026

View reviewed changes

rmi22186 reviewed Apr 3, 2026

View reviewed changes

alexs-mparticle requested changes Apr 3, 2026

View reviewed changes


		const selection = this.launcher!.selectPlacements(selectPlacementsOptions);

		// After selection resolves, sync the Rokt session ID back to mParticle

Conversation

mattbodle commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test plan

Uh oh!

mattbodle commented Apr 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mattbodle commented Apr 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mattbodle commented Apr 2, 2026 •

edited

Loading