Panda CSS v2: feature requests from a large-scale adopter

[kris-ellery]

Hey team 👋

First off, thank you for everything you've put into Panda. We use it across hundreds of repos (apps and packages) and have built our entire design system on top of it. We're deeply invested and want to see v2 succeed. Below is a list of features and improvements we'd love to see in Panda CSS v2. Happy to help shape APIs, write tests, or provide more detail on any of these. Just let me know.

---

🚀 Performance

1. Faster compilation engine (Rust / oxc / esbuild)

Large applications with thousands of paths and many packages can hit 30s+ build and rebuild times in watch mode. There may well be optimization opportunities in the current implementation, but a faster underlying engine would meaningfully change the experience at scale. As a proof point, I prototyped a Rust port that built a medium-sized app in under 100ms, so the approach is viable.

---

🎨 Tokens & CSS Output

2. Built-in optimizations (or official plugins) for CSS variable cleanup

Two specific wins:

• Remove unused CSS variables from the final output.
• Deduplicate CSS variables when used with staticCss: { themes: ['one', 'two'] }.

For projects with a lot of tokens, this can cut output size dramatically. I've seen ~50% reductions in some cases, but the exact impact scales entirely with the number of tokens defined. There's an unofficial pandabox plugin from one of the maintainers that does some of this, but it hasn't been updated and isn't first-party. Folding this into core (or maintaining it officially) would be a big win.

3. Public vs. private token visibility

Design systems typically have three layers of tokens: raw, semantic, and component. Today we can define tokens and semanticTokens, but we can't control which ones are exposed to consumers. Ideally, raw and component tokens would remain fully usable inside the design system package itself (for building components, deriving semantic layers, etc.), but get stripped from generated TS types and IntelliSense when the preset is consumed downstream. Only semantic tokens should surface to consumers.

4. Emit a JSON token map of what's actually in the compiled CSS

A build-time JSON artifact listing the tokens that made it into the final stylesheet would let consumers resolve values directly instead of maintaining a parallel token pipeline just to look up a value.

5. Atomic class deduplication for equivalent token references

color: 'red' and color: '{colors.red}' currently resolve to different atomic classes even though they reference the same value. This feels like a bug, flagging it here in case it can be folded into v2.

---

🌗 Theming

6. Built-in light-dark() emission for token CSS variables

An option or official plugin to emit CSS variables using the native light-dark() function, e.g.:

--colors-bg-neutral: light-dark(var(--colors-white), var(--colors-black));

This pattern significantly reduces duplicated light/dark theme CSS, but today it has to be hand-rolled.

---

📦 Multi-app, Federation & Distribution

7. Virtual / shared styled-system package

The current docs lean on per-package styled-system generation inside a monorepo, which works fine until you want to ship a design system to NPM and have many external apps consume it. Today the workaround is shipping dist files with @/styled-system and asking every consumer to alias it in their bundler config, which is fragile, easy to misconfigure, and hard to explain to teams.

A first-class story for a virtual or shared styled-system (one that the design system package, the consuming app, and any other Panda-built packages can all reference seamlessly) would unlock a lot for us.

8. Bundler plugins for true CSS tree-shaking from design systems

If a design system ships buildinfo for 100 components and an app imports only 10, the app still gets CSS for all 100. Two possible directions:

• Rethink how buildinfo works so unused component CSS doesn't ship.
• Provide official bundler plugins (Vite, webpack, etc.) that scan actually-imported modules and feed only those to Panda for CSS generation.

9. Federated module setup guidance and patterns

We'd love official guidance (and ideally features) for using Panda in federated module setups, where many isolated apps on the same page each use the design system or their own Panda-built components. Today we use hash prefixes plus shipping isolated styled-system methods and DS components with each federated module to avoid collisions. Workable, but heavy and hard to maintain.

10. Design-system-aware namespacing in hashing

Related to the federated case: if 10 MFEs (Micro Front-ends) use design system v10.10 and 2 use v10.14, we'd ideally see 2 CSS bundles (one per DS version), not 12. Factoring DS identity/version into the hash would let identical DS versions across MFEs naturally dedupe.

11. Buildinfo collision guidance across Panda versions

Related but distinct: when a host app and a recipe library are built against different Panda versions, buildinfo collisions can break things or produce conflicting output. Some official guidance, or features that prevent collisions outright, would help teams that can't always upgrade in lockstep.

---

🧩 Recipes & Variants

12. Responsive props + variant tree-shaking in regular recipes

This is technically possible with config recipes today, but config recipes require maintaining an explicit list of tracked JSX components. So if Button has responsive props and someone extends it to MyRedButton, they have to remember to add MyRedButton to the advanced JSX tracking list. That doesn't scale.

Ideally, responsive variants could be defined in regular recipes and tree-shaken (including compound variants) based on actual usage. The other reason we avoid config recipes: they generate named (non-atomic) class names and duplicate CSS output, while regular recipes stay atomic. So today we're stuck choosing between atomic output and tree-shaken responsive variants.

13. Ergonomic child targeting

Targeting child components today means falling back to raw selectors like > span, > div, or [data-ds-component="MyComponent"]. styled-components handled this nicely (though I'm not personally a fan of styled factories as the solution). I don't have a strong opinion on the API and am happy to leave the design to the team, but a more first-class way to target children would be very welcome.

---

🛠️ Developer Experience & Tooling

14. Better panda debug / diagnostics for missing classes

When a class is generated in source but doesn't appear in the final stylesheet (because of include globs, optimizations, patterns, etc.), Panda should explain why it was dropped (file, location, reason) instead of forcing devs to reverse-engineer it from config and logs.

15. A configurable linter (errors-only is fine)

Even a minimal linter that doesn't touch stylistic concerns would be valuable. As a starting point: a non-zero exit when the resulting CSS is invalid for any reason, with a file, line number, and a short explanation. Anything beyond that is bonus.

16. Official AI skills / guidelines

With AI-assisted coding becoming the default workflow, an official set of Panda CSS skills, best practices, and dos/don'ts (something LLMs and IDE assistants can ground on) would help teams keep usage consistent. Think recipe vs. atomic guidance, responsive patterns, token usage, things to avoid, all in a format suitable for AI tooling consumption.

---

Thanks again for all the work you've poured into this project. We're rooting for v2 and I'm happy to dig into any of these in more depth (APIs, tests, repros, whatever's most useful).

One last note: it's entirely possible some of these already have solutions or existing documentation that I've missed. Apologies in advance if that's the case, and pointers are very welcome.

[segunadebayo]

Really good points and ideas @kris-ellery.

Will share with the team and come back with some questions.

[jimmymorris]

Appreciate you and the team!

[segunadebayo]

@kris-ellery Could you share a bit more context around:
"Built-in light-dark() emission for token CSS variables"

Is this supposed to be set at the config.themes level for semantic tokens or at the css or cva call site?

[jimmymorris]

My thought was the semantic token level, keeping the components dumb, portable, and easier to reason about.

[segunadebayo]

Re: Public vs. private token visibility

I think this is best designed as a lint rule rather than enforced at the type level. Enforcing type-level changes introduces indirection, preventing authors from using the private tokens as well

[Jonas-C]

Just wanted to chime in with another idea for v2: We'd love if some of the project dependencies could be made optional. Ideally you'd be able to pick what framework plugin to install and a choice between installing postcss/lightningcss. Having the mcp package be optional would also be nice.

Furthermore, we've moved on from esbuild entirely. The only thing that's still pulling it in is panda. I'm not quite sure if there's a solid replacement for its usage in bundle-n-require, but maybe it's possibly to lean more closely on native node resolution when running panda codegen? This might tie in with the aforementioned bundler plugins.

Appreciate the continued work on all of your projects!

[zachbwh]

If there was a native implementation, it would be really nice to be able to connect that up to some native oxlint plugins as well so that whole DX can be super fast.

Thanks Kris for this very detailed post, I second most of them, particularly 1, 3, 7, 15, & 16

[leegunwoo98]

fully support the idea of porting to native. We are on a large codebase and even with all the optimization, build, rebuild is still very slow. Most of the time is spent on AST.

[segunadebayo]

Can you share more context around the slow build? How large is your codebase and design system setup?

Additional information would help tackle this better

[leegunwoo98]

sure sure happy to share.

Codebase scale

• Nx monorepo, 107 projects, ~4,200 TS/TSX files / ~574k LOC total.
• Panda include set (one shared panda.config.ts covering 2 React apps + ~18 frontend libs): 3,292 files / ~338k LOC — and that's after aggressive exclude hygiene
• Usage is essentially 100% atomic: ~5,100 styled() component definitions across ~2,100 files, plus ~550 css() call sites (we migrated the whole codebase off styled-components). jsxFramework: "react".
  ``

Design-system setup

Deliberately minimal — which is what makes the timings interesting:

• default preset tokens only (no custom token layers yet), no config recipes, no staticCss, no themes
• custom breakpoints + 72 keyframes + a small globalCss block
• preflight: false, strictTokens: false, lightningcss: true
• emitted sheet: ~526KB

Measured times (CLI mode — the recommended/faster path)

Operation	Cost
Full one-shot panda (codegen + cssgen, 3,292 files)	~52s CPU / 61s wall, 3.3GB peak RSS (fresh run today; Panda's own log: Successfully extracted css from 3292 file(s) (48572ms)); 57–80s CPU / 2.2–3.3GB across earlier runs
panda --watch initial build	full re-extraction again — a dev-server boot that wants both codegen and watch pays extraction twice
Watch mode: save → styles.css rewritten	~5s CPU floor per save (re-parse the changed file + re-serialize the full 526KB sheet); 13–50s wall when the machine is busy

Where the time goes

--cpu-prof over the full one-shot, self-time grouped by package:

Component	Share
@ts-morph/common (bundled TS compiler: scan/parse/bind)	53.8%
V8 GC (induced by AST churn; evenly spread, not a late spike)	22.6%
ts-morph wrapper (node wrapping/traversal)	9.4%
native I/O (read + stat)	6.2%
@pandacss/extractor	2.0%
@pandacss/core (cssgen)	1.0%
postcss + lightningcss	0.2%

≈86% is TypeScript parse/bind plus the GC it induces; Panda's own logic is ~3%. That's why a faster parsing engine (oxc/Rust, as in the OP) looks like the only lever that meaningfully moves the needle at this scale — include hygiene shrinks the file set, but not the per-file cost.

[segunadebayo]

This is very useful. Thanks for sharing

[Jonas-C]

Another improvement I'd really appreciate: A way to generate less complex d.ts files. If I export a component that accepts variants the entire recipe css is defined in the d.ts file. This pretty much locks us out from using isolatedDeclarations.

[Adebesin-Cell]

Hey @Jonas-C @kris-ellery @leegunwoo98 @zachbwh @jimmymorris,

Sorry for the many pings! Just wanted to let you know that v2 is now in beta, and we'd love for you to give it a try and see how it feels. If you run into any issues at all, feel free to comment here: #3599

[leegunwoo98]

ah yes. I was actually checking it out a few hours ago. We saw a significant increase in performance. I am checking if this was a fluke by loosing some output css files. But right now, I am pretty confident that we are seeing 17x in total time, 50x in cpu time and 25x in the amount of RAM it is using. Will give you a better report when I am finished checking if we have any losses

[leegunwoo98]

	v1 (1.11.x, ts-morph)	v2 beta (Rust/Oxc)
Wall time	~64 s	~3.8 s (~17× faster)
CPU time	~76 s	~1.5 s (~50× less)
Peak memory	~4 GB	157 MB (~25× less)
Output	121 files / 579 KB CSS	119 files / 558 KB CSS

The generated CSS came out essentially equivalent — actually a touch smaller (more atomic selectors merged into fewer rule blocks, looks like the adjacent-selector merging doing its thing; coverage checks out).

We haven't done a full production migration yet (still validating build + visual parity), but the compiler speedup alone is a massive win. Only config tweak we needed was adding presets: ["@pandacss/preset-base"]. Will drop anything we hit into #3599 — thanks for the great work on this! 🙏