The micro-frontend platform powering all Pandora web apps
npx @pandora/create-pandora-react-app@latest
SPARK 2.0 is Pandora's internal platform for building and deploying web applications as independently deployable micro-frontends. It provides a battle-tested boilerplate, a scaffolding CLI, and a shared component ecosystem — so every team starts with the same quality bar, zero boilerplate setup, and full production readiness from day one.
The Architecture Team maintains a single source-of-truth Next.js 16 boilerplate with the full stack pre-configured. Teams never clone it directly.
create-pandora-app prompts for app type, name, and port — then generates a fully configured project in seconds, published via Azure Artifacts.
Module Federation powers CSR-based remote loading between verticals. Each app is independently deployable — no coupled releases.
Shared components, store context, and utilities live in the @pandora/* scope on Azure Artifacts, consumed by every app.
Every SPARK app is one of four types. The CLI scaffolds the right wiring automatically.
Owns a set of URL paths (e.g. /collections/*). Acts as both host and remote — loads peer apps at runtime via createInstance() + loadRemote().
Pure remote fragment — no owned URLs. Embedded by verticals at CSR. Never loads other remotes.
Full Next.js app with no Module Federation wiring. Gets the full SPARK tooling stack without MFE complexity.
Reusable TypeScript package published to the @pandora/* scope on Azure Artifacts. Consumed across all app types.
Runs next dev --webpack on its own port. Loads peer remotes at CSR using createInstance() + loadRemote() with ssr: false.
Runs alongside Next.js via concurrently. Builds remote output to public/_next_mf/ — served statically by Next.js from disk.
Each remote is reachable at /_next_mf/static/chunks/mf-manifest.json. No separate server needed.
react, react-dom, @pandora-ecom/store-context, @pandora-ecom/shared-components — all eager: true.
AppRouterContext — use NavigationLink for cross-app navigation--webpack flag is required — Turbopack does not support Module Federationpnpm dev — nothing extra to configure
Two shared packages live in the @pandora-ecom/* scope on Azure Artifacts.
Every SPARK app declares them as peer dependencies — they are also listed as
Module Federation shared singletons, so only one instance loads
across all remotes at runtime.
The Pandora UI design system — layout shells, navigation primitives, error/loading states, and Module Federation utilities consumed by every app.
@pandora-ecom/shared-components/navigation — each vertical MFE has its own AppRouterContext, so cross-app links must go through NavigationLink.
Shared React context for cross-app state — cart, providers, and any global store that must be the same instance across all micro-frontends at runtime.
eager: true) — all remotes share the same cart state instance. Never bundle separate copies.
localePrefix: always. Missing key checks run in CI via i18n-check.
Env.ts. Never read process.env directly.
useMemo or useCallback needed in app code.
@/ prefix. No ../../.. paths anywhere in app code.
Teams never clone this repo. They scaffold a new app from it in four steps.
Add the Pandora npm feed to ~/.npmrc and log in with an Azure DevOps PAT (scope: Packaging → Read). One-time setup per machine.
Answer three prompts — app type, name, and port. The CLI generates a fully configured project with the right template overlay applied.
Install dependencies and start the dev server. For MFE app types, both Next.js and the MF webpack script start automatically.
Everything is pre-wired — i18n, feature flags, env validation, testing, CI pipeline. Just start building.