Problem
The html package currently exports components with a Demo suffix (e.g. ButtonDemo, GridDemo, etc.) alongside the official spec components from its main entry point. These Demo components are not the same as the spec components — they serve a different purpose (visual test scenarios, showcases).
Projects like SakurAI that do import * from "@progress/kendo-themes-html" (or similar barrel imports) unintentionally pick up all Demo exports in addition to the official spec components. SakurAI only needs the spec components — the Demos pollute its namespace and can cause confusion or incorrect usage.
Meanwhile, ThemeBuilder only needs the Demo components, not the specs.
Proposed Solution
Introduce a dedicated /demos sub-path export (e.g. @progress/kendo-themes-html/demos) so that:
- The main index (
/) exports only spec components.
- The
/demos sub-path exports only Demo components.
Migration Plan (two steps)
Step 1 — Dual export (non-breaking)
- Export Demo components from both the main index (
/) and the new /demos sub-path.
- If feasible, mark the Demo re-exports in the main index as
@deprecated (via JSDoc / TSDoc) so consumers get IDE warnings nudging them toward the new /demos path.
- This gives downstream projects time to update their imports without breakage.
Step 2 — Remove Demos from main index (breaking)
- Once all known consumers have migrated their Demo imports to the
/demos path, remove the Demo re-exports from the main index.
- After this step:
- Main index → spec components only
/demos → Demo components only
Affected Consumers
| Project |
Needs |
Current state |
Action needed |
| SakurAI |
Spec components only (no Demos) |
Gets everything via barrel import |
No change needed — Step 2 will clean up the index automatically |
| ThemeBuilder |
Demo components only |
Imports from main index |
Switch Demo imports to /demos path before Step 2 |
Acceptance Criteria
Problem
The
htmlpackage currently exports components with aDemosuffix (e.g.ButtonDemo,GridDemo, etc.) alongside the official spec components from its main entry point. These Demo components are not the same as the spec components — they serve a different purpose (visual test scenarios, showcases).Projects like SakurAI that do
import * from "@progress/kendo-themes-html"(or similar barrel imports) unintentionally pick up all Demo exports in addition to the official spec components. SakurAI only needs the spec components — the Demos pollute its namespace and can cause confusion or incorrect usage.Meanwhile, ThemeBuilder only needs the Demo components, not the specs.
Proposed Solution
Introduce a dedicated
/demossub-path export (e.g.@progress/kendo-themes-html/demos) so that:/) exports only spec components./demossub-path exports only Demo components.Migration Plan (two steps)
Step 1 — Dual export (non-breaking)
/) and the new/demossub-path.@deprecated(via JSDoc / TSDoc) so consumers get IDE warnings nudging them toward the new/demospath.Step 2 — Remove Demos from main index (breaking)
/demospath, remove the Demo re-exports from the main index./demos→ Demo components onlyAffected Consumers
/demospath before Step 2Acceptance Criteria
/demossub-path export is available and contains all Demo components@deprecatedannotations/demospath before Step 2 lands