Consumer migration path (spike)

[eddiman]

Description

Define the migration path for existing consumers onto the redefined tokens. This is the main open risk — the UI-kit userbase is growing weekly and some currently mix static + dynamic colour.

Decided principle

• Static only, no mixing. Mixing static + dynamic forces importing a second CSS file, inflating bundle / load size.
• Transition handled via beta flags → 3.0.0 full release (see the packaging issue).

Scope (spike)

• Map the concrete old → new path for existing consumers, including those who mix static + dynamic today.
• Identify breakage points and the minimum-viable migration steps / guidance.

Definition of Done

• Old → new migration path documented
• Mixed static/dynamic consumers addressed
• Migration guidance drafted for consumers

[claude]

These issues look closely related and may provide useful context for this spike:

• 📦 eds-tokens packaging & release (beta flags → 3.0.0) #5120 — 📦 EDS 3.0 packaging & release (beta flags → 3.0.0) (open): this is the "packaging issue" referenced here; it owns the beta-flag → 3.0.0 transition that this migration path depends on.
• 🧩 Component migration (colour, then spacing & typography) #5119 — 🧩 EDS 3.0 component migration (colour, then spacing & typography) (open): defines how components move onto the new tokens, the other half of the old → new migration story.
• Swap dynamic colour → static internally #5118 — Swap dynamic colour → static internally (EDS 3.0) (open): the internal dynamic → static swap that underpins the "static only, no mixing" principle decided here.
• Explore codemods for EDS 1.0 → 2.0 migration #4484 — Explore codemods for EDS 1.0 → 2.0 migration (open): prior art on automating consumer migration paths and drafting migration guidance.

This comment was generated by an LLM and may be inaccurate. Please verify that the linked issues are actually relevant.