📦 eds-tokens packaging & release (beta flags → 3.0.0)

[eddiman]

Description

Package and release strategy for the redefined tokens. Ship under beta flags during the transition, then a full major release — deliberately not rushed (last time tokens were pushed out of beta too quickly; this time the beta is verified against real components first).

Scope

• During transition: eds-core-react continues under a beta flag; eds-tokens gets the new token structure under a beta flag.
• Iterate and verify the beta against real components, gather feedback, adjust before going stable.
• Full release: EDS core (react) + tokens released together as one major (likely 3.0.0) — a single clear breaking change for both.
• Keep the existing EDS 2.0 tokens in place but mark them "do not use."
• Pure component-consumers: no change.

Definition of Done

• Beta-flagged eds-tokens published and verified against components
• Old tokens marked "do not use"
• Release notes / changelog prepared

Timeline: stable release not this year — beta first, iterate on feedback.

[claude]

These issues look closely related — both as sibling work in the EDS 3.0 effort and as prior art for the beta-flag release mechanics:

• 🧩 Component migration (colour, then spacing & typography) #5119 — 🧩 EDS 3.0 component migration (colour, then spacing & typography) (open): sibling EDS 3.0 epic item; the components being migrated are what ship under the beta flags described here.
• Consumer migration path (spike) #5121 — Consumer migration path to EDS 3.0 (spike) (open): directly informs the "pure component-consumers: no change" goal and the eventual 3.0.0 upgrade path.
• Pause new component development during the token transition #5122 — Pause new component development during the EDS 3.0 transition (open): covers the same transition window during which packages ship under beta flags.
• chore: re-add eds-tokens to release-please config after beta #4591 — chore: re-add eds-tokens to release-please config after beta (closed as completed): prior precedent for beta-flagging eds-tokens by temporarily removing it from release-please-config.json/release-please-manifest.json, then re-adding for the stable release — the exact mechanism needed here.
• chore(eds-tokens): re-add to release-please after beta #4592 — chore(eds-tokens): re-add to release-please after beta (closed as duplicate of chore: re-add eds-tokens to release-please config after beta #4591): same release-please beta workflow.

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

[pomfrida]

Implementation notes from the (now closed) duplicate #5172, so they live here:

• The beta flag can mirror the existing eds-core-react-next setup in .github/release-please-config.json (prerelease-type: beta) — publish 3.0.0-beta.x under the npm dist-tag beta while 2.x stays latest, so testers keep their import specifiers unchanged (npm i @equinor/eds-tokens@beta)
• On the beta line: add the pipeline-generated directories (src/tokens/{css,dtcg,ts} from the Tokens Studio release workflow) to the package files field and repoint the exports map specifiers (./css/variables etc.) — today none of the generated output is published
• Decide the fate of the ./ts/* subpath exports with the mobile team — equinor/design-system-mobile imports six TS modules, and the new density dimension has no spacious (see Generate TypeScript tokens in the Tokens Studio pipeline #5164 for the usage mapping)
• npm trusted publisher allows only one workflow per entry — a new/changed publish workflow for the beta line needs its trusted-publisher entry updated
• Blocked by the token architecture rework (ADR: Token variable architecture — Figma structure (typography & spacing) #5139) landing, so the beta does not ship names that immediately change again