Context
I'm doing a full audit of Lighthouse → @juspay/svelte-ui-components migrations and one category is genuinely architecturally unaddressable today: charts. The library has zero chart components — Gauge is the closest, and Progress is a one-dimensional bar.
Lighthouse ships a Funnel component (3 callsites: GA4Report, ShopifyBreezeReport, DynamicReport) plus various dashboard chart shapes (line charts, donut charts, sparklines, breakdown panels). These are real product needs and they don't have a library home.
Question for maintainer
What's your position on charts as a library surface?
Option A — out of scope, explicit. Library is UI primitives only; charts stay in consumer projects, possibly with a @juspay/charts-svelte sibling library if shared use cases emerge. If this is the call, please confirm so I can stop trying to find a library home for these and document it clearly in CLAUDE.md.
Option B — in scope eventually, with a primitive philosophy. Library could ship a small set of chart primitives (<Funnel>, <LineChart>, <BarChart>, <DonutChart>) following the same slim philosophy: data-array input + snippet for per-segment rendering + CSS vars for theming, no baked color palettes, no opinionated tooltips. Consumers compose.
Option C — wrap a battle-tested chart lib. Library imports a peer like ECharts / Visx / D3 / uPlot and ships a thin Svelte wrapper. (I'd argue this contradicts the library's "no runtime deps the consumer didn't already opt into" pattern, but flagging for completeness.)
I'd lean towards A for now — charts are heavy enough that they likely warrant their own sibling library rather than bloating this one — but I want the explicit call so Lighthouse can plan accordingly. Right now Funnel migration is sitting in the "blocked, awaiting library decision" column.
Recommendation
Pick A or B explicitly. Either way, document the answer in the library README so future contributors don't keep trying to land chart PRs that get rejected.
Context
I'm doing a full audit of Lighthouse →
@juspay/svelte-ui-componentsmigrations and one category is genuinely architecturally unaddressable today: charts. The library has zero chart components — Gauge is the closest, and Progress is a one-dimensional bar.Lighthouse ships a
Funnelcomponent (3 callsites:GA4Report,ShopifyBreezeReport,DynamicReport) plus various dashboard chart shapes (line charts, donut charts, sparklines, breakdown panels). These are real product needs and they don't have a library home.Question for maintainer
What's your position on charts as a library surface?
Option A — out of scope, explicit. Library is UI primitives only; charts stay in consumer projects, possibly with a
@juspay/charts-sveltesibling library if shared use cases emerge. If this is the call, please confirm so I can stop trying to find a library home for these and document it clearly in CLAUDE.md.Option B — in scope eventually, with a primitive philosophy. Library could ship a small set of chart primitives (
<Funnel>,<LineChart>,<BarChart>,<DonutChart>) following the same slim philosophy: data-array input + snippet for per-segment rendering + CSS vars for theming, no baked color palettes, no opinionated tooltips. Consumers compose.Option C — wrap a battle-tested chart lib. Library imports a peer like ECharts / Visx / D3 / uPlot and ships a thin Svelte wrapper. (I'd argue this contradicts the library's "no runtime deps the consumer didn't already opt into" pattern, but flagging for completeness.)
I'd lean towards A for now — charts are heavy enough that they likely warrant their own sibling library rather than bloating this one — but I want the explicit call so Lighthouse can plan accordingly. Right now
Funnelmigration is sitting in the "blocked, awaiting library decision" column.Recommendation
Pick A or B explicitly. Either way, document the answer in the library README so future contributors don't keep trying to land chart PRs that get rejected.