Skip to content

Overview

A self-contained reference for what WhiskerPlatform is, how its pieces fit together, how external teams plug into it, and where it is brittle.

These documents assume the reader is technical but unfamiliar with the platform. Read them in order, or jump to the section relevant to your task. Each document separates what’s built and running today from what’s planned or proposed — look for the “Planned” sections rather than assuming everything described is live.

Where the platform stands. The tooling stack (@nike/whisker-cli, @nike/create-whisker, @nike/whisker-module-kit, @nike/whisker-service-kit) is feature-complete for a first Artifactory pilot but not yet published; @nike/whisker-component-library is the only package published today. The biggest missing platform piece is whisker-bff — the host still calls the legacy sim-bff for manifests and login. See Manifest pipeline & deployment and Risks & improvements.

Document Read if you want to…
WhiskerPlatform Architecture See the system diagram, runtime flow, and the two integration paths in detail
Scaffolder & kits Know how create-whisker, whisker-module-kit, and whisker-service-kit work
Host ↔ module contract Understand the federation and iframe integration paths and how they are kept stable
Manifest pipeline & deployment Trace a manifest from src/moduleManifest.ts to a user’s browser, including S3 co-location and the publisher Lambda
Component library Use or contribute to @nike/whisker-component-library
Automation, devkit & E2E Understand whisker doctor, the (planned) devkit panel, and the nightly Playwright runner
AI-first tooling See how Thundercats / @nike/whisker-cli brings Nike context to AI agents
Consumer integration guide Onboard an external team — federation module or iframe consumer
Risks, brittleness, improvements Know where the platform is fragile and what we should fix next
rwe-core vs whisker-host Compare the two host implementations side by side
Manifest schema reference Understand what each part of ModuleManifest is for and how it’s namespaced
Analytics architecture Understand the three-layer analytics system shared by host + modules
  • Host” refers to whisker-host (the runtime shell users open in a browser).
  • Module” is anything declared by a module-manifest.json — a federation remote or an iframe consumer.
  • Kit” refers to the developer-facing devDependency that ships a CLI — @nike/whisker-module-kit (front-end) or @nike/whisker-service-kit (back-end).
  • Scaffolder” refers to @nike/create-whisker, the one-time-use generator invoked through pnpm create whisker.
  • Each doc’s “Planned / proposed” section is not yet running in production — treat it as intent, not as something you can depend on today.