Panda v2 feedback

[Adebesin-Cell]

Panda v2 is in beta. Same Panda you know, css(), recipes, patterns, tokens, conditions. The engine underneath is rewritten in Rust. It's fast, and it's still rough in spots. This is where you tell us about both.

Install:

npm i -D @pandacss/dev@beta

Start here: v2 beta guide & migration — setup, what changed, and what is in progress.

What helps most:

• CSS that doesn'''t match v1. Differences are the most useful thing you can report.
• Build errors, broken extraction, framework quirks.
• Run panda debug and attach the dump from <outdir>/debug — it's how we reproduce.

And the wins 🎉

We'd love to hear those too. Faster builds, a smooth migration, something that just worked, drop it here. Numbers (before/after build times, bundle size) are great, but "it felt snappier" counts too.

Found a bug with a repro, shipped v2 to production, or just thinking out loud, or stuck on setup? Drop it here.

[zachbwh-secure-fresha]

Awesome work! I'll give it a test soon and provide any feedback

[finnan444]

v2 regression: nested &.class + & .descendant flattens the class onto the descendant instead of the ancestor

Versions: @pandacss/dev@2.0.0-beta.2, compared against 1.11.3.

Minimal repro

import { css } from '../styled-system/css'

css({
  '&.is-open': {
    '& .child': { color: 'red' },
  },
})

Generated CSS

v1 (1.11.3) — correct (also on the playground, pinned to 1.11.3: https://play.panda-css.com/8HetlUQ1Wc):

.\[\&\.is-open\]\:\[\&_\.child\]\:c_red.is-open .child { color: red }
/* selector: .atomic.is-open .child */

v2 (2.0.0-beta.2) — wrong:

.\[\&\.is-open\]\:\[\&_\.child\]\:color_red .child.is-open { color: red }
/* selector: .atomic .child.is-open */

Why it's wrong

By the CSS-nesting expansion, &.is-open { & .child {} } on a .atomic element should be
.atomic.is-open .child. v2 instead emits .atomic .child.is-open: the compound .is-open
from the outer & is reattached to the inner descendant. A state class on the parent therefore
never matches, so the rule silently does nothing.

Same break in sva slot recipes (where I originally hit it). A slot with

selector: {
  '&.selector-open': {
    '& .selector__menu': { opacity: '1' },
  },
}

generates <atomic> .selector__menu.selector-open in v2 — i.e. it now requires .selector-open
on the menu slot itself rather than on the parent, so the open state never applies.
Workaround that does generate correct CSS in v2: move the rule into the target slot using the
ancestor form '.selector-open &': { ... } → .selector-open <atomic>.

panda debug dump available on request.

[Adebesin-Cell]

Hey! Thanks for the precise repro, this is fixed on v2 already, it just hasn't been released yet.

css({ '&.is-open': { '& .child': { color: 'red' } } })
// now emits  .atomic.is-open .child   (was .atomic .child.is-open on beta.2)

Your sva slot case ('&.selector-open': { '& .selector__menu': {...} }) is correct too now, the open-state class stays on the parent.

The fix landed in 3609

It'll be in the next @pandacss/dev@beta. I'll follow up here once that's published.

[finnan444]

fixed on 2.0.0-beta.3

[finnan444]

v2 regression: Oxc extractor fails on top-level return in .astro frontmatter (valid Astro), aborts the build

A .astro component with a top-level return in its frontmatter builds fine under v1 but breaks the whole build under v2. The frontmatter is valid Astro — Astro compiles the frontmatter as the body of the component's render function, so a top-level return is legal there — but v2's Oxc-based extractor parses the frontmatter as a bare ES module, where return outside a function is a hard SyntaxError.

Env

• @pandacss/dev / @pandacss/postcss 2.0.0-beta.2
• Astro 6, PostCSS pipeline, macOS arm64 (@pandacss/compiler-darwin-arm64)

Minimal repro — src/Foo.astro:

---
import { SOME_FLAG } from 'astro:env/client'
if (SOME_FLAG === '') {
  return null
}
---
<div />

Default include: ['./src/**/*.{ts,tsx,js,jsx,astro}'].

Behavior

• v1 (1.11.x, ts-morph extractor): builds fine.
• v2 (2.0.0-beta.2, Oxc): panda cssgen exits 1, and through @pandacss/postcss the full astro build fails:

error js_parse_error src/Foo.astro:3:2
A 'return' statement can only be used within a function body.

astro build itself compiles the same file without error — only Panda's extractor rejects it.

Root cause

Per V2_MIGRATION.md, extraction moved from ts-morph/ts-evaluator to a native Oxc engine ("one parse per file"). Oxc parses the stripped .astro frontmatter in module mode; Astro's own compiler wraps it in a render function, so return is valid there but not in a bare module.

Asks

1. Parse .astro frontmatter in a context where a top-level return is legal (wrap in a function / script goal), matching Astro semantics.
2. Make a per-file parse error non-fatal — skip + warn — instead of aborting the whole build for a single unparseable file (especially one with no Panda usage). Today one bad file kills the build via the PostCSS plugin.

Current workaround: exclude: ['./src/Foo.astro'].

This regression isn't mentioned in V2_MIGRATION.md.

[Adebesin-Cell]

Hey! Thanks a lot for spotting this. A new beta has just been released. Give it a try and let us know if it's sorted on your end

[finnan444]

fixed on 2.0.0-beta.3