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.

Please share BEFORE / AFTER data as well for cssgen and codegen

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

[Jonas-C]

Are there any alternatives to panda cssgen --minimal? We export style sheets per package in a monorepo, and including the tokens in every stylesheet would be unfortunate.

[segunadebayo]

Indeed. Sounds like a flag regression. Let me check it out

Update: It's now fixed in the v2 branch, will do a release shortlly

[segunadebayo]

fixed in 2.0.0-beta.4

[Jonas-C]

Another bug that's currently blocking us: textStyles doesn't seem to resolve when used in globalCss. It's just dropped entirely.

[segunadebayo]

This is now fixed in the v2 branch, will release a new version shortly.

[segunadebayo]

fixed on 2.0.0-beta.4

[Jonas-C]

Not entirely sure whether this happens all over, or only in globalCss, but I noticed that some code looking like this failed to be extracted:

  ".article": {
    h2: {
      color: "blue"
    }
  }

Seems like v1 was more lenient here. If I do "& h2" the css is generated.

[segunadebayo]

Oh yes, adding & is now required for nested selectors. Will add it to the migration guide.

[Jonas-C]

In a similar vein to my previous comment, this snippet produces unexpected css:

  ".article": {
    "h2, h3, h4": {
      color: "blue"
    }
  }

It produces:

.article h2, h3, h4 {
  color: blue
}

It should produce:

.article h2, .article h3, .article h4 {
  color: blue
}

[segunadebayo]

Please use the & rule here to resolve this.

 ".article": {
     // & h2, & h3,  & h4
    "&:is(h2, h3, h4)": {
      color: "blue"
    }
  }

but yeah, we should fix this as well. PR to fix this should be merged shortly

[Jonas-C]

Another issue I'm encoutering is overriding font-families of a specific text style. Let's use the following code as an example:

".codeblock": {
  textStyle: "label.medium",
  fontFamily: "code",
}

In v1, this generated into a single block of css. In v2, it generates into two: One block that includes the non-composition css, and another that includes the text style. This causes me to never be able to override for instance the font-family.

The v2 output is something like:

  .codeblock {
    font-family: var(--fonts-code);
  }
  .codeblock {
    font-family: var(--fonts-sans);
    font-size: var(--font-sizes-small);
    font-weight: var(--font-weights-normal);
    letter-spacing: normal;
    line-height: var(--line-heights-small);
  }

[Adebesin-Cell]

Hmm, seems like a regression. Let me check them out. Thanks! 👍

[Jonas-C]

Seems like there's a diff with using grid-template-areas as well. Probably not noteworthy, but I found the css naming to be strange so I thought I'd report it.

Original code:

  gridTemplateAreas: `
      "preview name delete" 
      "preview size delete"`,

v1 output:

  .grid-template-areas_\"preview_name_delete\"_\"preview_size_delete\" {
    grid-template-areas: "preview name delete" "preview size delete";
}

v2 output:

  .grid-template-areas_\"preview_name_delete\"_\a______\"preview_size_delete\" {
    grid-template-areas: "preview name delete" 
      "preview size delete";
  }

[segunadebayo]

This is now fixed.

[Jonas-C]

Worth mentioning in the migration docs (maybe?): text-decoration: "none" now generates to td_none, used to be text-decoration_none.

[finnan444]

v2 regression: a textStyle (composition) used inside a recipe base/variants drops every property that has a conditional (responsive) value

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

When a recipe composes a textStyle (or any composition token) whose value contains conditional/responsive properties ({ base, xs, ... }), v2 emits only the flat string properties. Every property whose value is an object is dropped entirely — not just the breakpoint variants, the base value too. Plain css({ textStyle }) is unaffected; only the recipe path breaks.

Minimal repro — panda.config.ts:

const textStyles = defineTextStyles({
  body: { value: {
    fontFamily: 'Montserrat, sans-serif',
    fontSize:   { base: '14px', xs: '16px', xl: '20px' },
    fontStyle: 'normal', fontWeight: '500',
    lineHeight: { base: '18px', xs: '20px', xl: '26px' },
  } },
})

// A) composes the textStyle
const viaTextStyle = defineRecipe({ className: 'viaTextStyle', base: { textStyle: 'body' } })

// B) control: the SAME values written inline in base
const inlined = defineRecipe({ className: 'inlined', base: {
  fontFamily: 'Montserrat, sans-serif',
  fontSize:   { base: '14px', xs: '16px', xl: '20px' },
  fontStyle: 'normal', fontWeight: '500',
  lineHeight: { base: '18px', xs: '20px', xl: '26px' },
} })

// theme.extend: { textStyles, breakpoints: { xs: '480px', xl: '1280px' }, recipes: { viaTextStyle, inlined } }

Both recipes are used once each: viaTextStyle() and inlined().

cssgen — v1 (1.11.3), correct. Both recipes produce identical output (Panda even merges the selectors), with all responsive values:

@layer recipes{
  @layer _base{
    .viaTextStyle,.inlined {
      font-family: Montserrat, sans-serif;
      font-size: 14px;
      font-style: normal;
      font-weight: 500;
      line-height: 18px;
    }
    @media screen and (min-width: 30rem) {
      .viaTextStyle,.inlined { font-size: 16px; line-height: 20px; }
    }
    @media screen and (min-width: 80rem) {
      .viaTextStyle,.inlined { font-size: 20px; line-height: 26px; }
    }
  }
}

cssgen — v2 (2.0.0-beta.4), wrong. The inlined control is correct, but viaTextStyle loses font-size and line-height completely:

@layer recipes {
  @layer base {
    .inlined {
      font-family: Montserrat, sans-serif;
      font-size: 14px;
      font-style: normal;
      font-weight: 500;
      line-height: 18px;
    }
    @media (width >= 30rem) { .inlined { font-size: 16px; line-height: 20px; } }
    @media (width >= 80rem) { .inlined { font-size: 20px; line-height: 26px; } }

    .viaTextStyle {
      font-family: Montserrat, sans-serif;
      font-style: normal;
      font-weight: 500;
      /* ← font-size and line-height gone, including the base value */
    }
  }
}

Why it's wrong

fontSize/lineHeight are the two properties whose textStyle value is conditional. The flat props (fontFamily, fontStyle, fontWeight) survive; the conditional ones vanish. The inlined control proves recipe base handles conditional values fine on its own — the breakage is specific to expanding a composition token inside a recipe. Extraction is fine too: the panda debug dump shows both recipe calls correctly recognized (category: "recipe", empty data), so this is purely in recipe CSS serialization.

Not the same as the two textStyle comments already in this thread: this is the recipe path (not globalCss, not plain css()), and the symptom is conditional properties silently dropped, not a cascade/override split.

Impact: any recipe built on a responsive textStyle silently loses its responsive typography. Easy to miss because the flat properties still render.

panda debug dump available on request.

[Adebesin-Cell]

Hey! Thanks for taking the time to track this down. There's a release in progress, it'll ship in 2.0.0-beta.5.

[finnan444]

v2 regression: a string value that matches a token name now resolves to the token instead of the CSS keyword

@pandacss/dev@2.0.0-beta.5 vs 1.11.3.

lineHeights (from preset-panda) contains a token named normal (1.5). When you write a value that is both a valid CSS keyword and a token name, v2 now resolves it to the token; v1 emitted the literal keyword.

defineTextStyles({
  heading: { value: { lineHeight: 'normal' } },
})

/* v1.11.3 */  line-height: normal;
/* v2 beta */  line-height: var(--line-heights-normal); /* = 1.5 */

This silently changes the computed value (keyword normal ≈ font-dependent ~1.2 vs 1.5). The same would happen for any keyword colliding with a token name (auto, none, etc.).

Expected: a bare CSS keyword should stay a keyword; the token should require explicit opt-in (e.g. lineHeight: 'token(lineHeights.normal)').

[segunadebayo]

v2 is more correct here; the solution would be to avoid using css keywords as token names in v2's preset.

Let me have a think about that and we'll update it as needed

[finnan444]

Agreed, the deterministic rule (token name always wins) is the more consistent choice — special-casing per-property CSS keywords would be fragile.

One thing worth keeping in mind when fixing it in the preset: the same collision exists in user configs, not just preset-panda. lineHeights: { normal: ... } is a common pattern (it's in Tailwind and many design systems), so renaming the preset tokens alone won't fully prevent it. Might be worth:

• calling this out explicitly as a breaking change in the v2 migration guide, and
• optionally a build-time warning when a token name collides with a valid CSS keyword for that property.

That way the footgun is visible even for people with their own keyword-named tokens.

[Jonas-C]

I just noticed that our .css file contains a couple of invalid css attributes, namely px and mx. This is probably due to two separate bugs:

• Panda somehow scans the patterns folder in our styled-system, and generates css rules for patterns regardless of whether they're used or not. In this case panda somehow picks up the container recipe.
• We've explicitly disabled shorthands in all of our packages. Seems like the code generation doesn't account for this.

[segunadebayo]

I've confirmed those bugs. Looking into this

[segunadebayo]

@Jonas-C Could you share any interesting wins you found in your project? I'm curious to know about it.

[Jonas-C]

Wins from panda v2, or panda in general?

[Adebesin-Cell]

Panda v2

[Jonas-C]

Haven't ran any concrete benchmarks yet, but it seems like v2 shaves off around 25% of our build pipeline time! Furthermore, storybook boots up a lot quicker. I'll provide better benchmarks once we've migrated our monorepo and can deploy it to our frontends!

[finnan444]

v2-beta: atomic CSS is generated from props of non-Panda capitalized components (regression vs 1.11.1)

Feedback on the new engine's extraction. In 2.0.0-beta.5 (also repro'd on beta.3) the
extractor emits atomic utilities from any prop on a capitalized (component) element whose name matches a
utility/shorthand — even when the component is not a styled component, never imports
Panda, and doesn't forward the prop as a style. 1.11.1 doesn't do this. No jsxFramework
is configured, so JSX style-prop extraction isn't expected to run at all.

(Possibly related to the "patterns generating invalid shorthand despite being disabled"
item above, but this is component props, not patterns — filing separately in case it's
a distinct path.)

Env: @pandacss/dev@2.0.0-beta.5 (vs 1.11.1 OK) · astro 6.4.4 (postcss integration)
· bun 1.3.14 · node 24 · no jsxFramework, strictTokens+strictPropertyValues on.

Minimal repro

src/components/Box.astro — plain component, no Panda, props unused for styling:

---
interface Props { width?: string; height?: string; direction?: string; foo?: string }
const { foo } = Astro.props
---
<div data-foo={foo}>hi</div>

src/pages/index.astro — no css()/recipe calls anywhere:

---
import Box from '@/components/Box.astro'
---
<img src="/x.png" alt="" width="1111" height="2222" />   <!-- lowercase HTML el -->
<Box width="5555" height="6666" direction="reprodir" foo="bar" />  <!-- component -->

panda cssgen -o out.css   # also reproduces through `astro build`

Expected (= 1.11.1)

No utilities from <Box>. out.css has none of .w_5555 / .h_6666 / .direction_reprodir.

Actual (2.0.0-beta.5)

.w_5555 { width: 5555px }
.h_6666 { height: 6666px }
.direction_reprodir { direction: reprodir }   /* invalid value */

What pins the trigger:

• Capitalized component prop → extracted; lowercase HTML attribute (<img width="1111">) → not (correct).
• Only utility/shorthand-named props are taken: width/height/direction emitted, foo not.
• Reproduces via both panda cssgen and astro build.

Why it bites in practice

This fires on every astro:assets <Image width="…" height="…"> (e.g. .w_900{width:900px},
.h_800{height:800px}) and on a slot-recipe component taking direction="forward|backward"
→ .direction_forward{direction:forward} (invalid). Result: dead CSS that
optimize.removeUnusedTokens doesn't strip (it prunes vars, not atomic classes) plus invalid
declarations shipped to prod. Nearly every Astro+Panda project uses <Image width height>, so
they're silently affected after upgrading.

Is extracting style props from arbitrary capitalized components (no jsxFramework, no
styled) intended in v2? If so, what's the opt-out?

[segunadebayo]

This is fixed in the v2 branch. Will be out in the next release

[segunadebayo]

@finnan444 could you share any interesting wins you found in your project so far? for Panda v2?

[finnan444]

@segunadebayo Honestly, my motivation wasn't a specific "win" — I run a few projects on Panda and a major bump is inevitable, so I jumped on the beta early to surface problems before stable. That's where the regressions in #3599 came from.

The one thing that genuinely landed well: explicit presets. Declaring preset-base (+ my own preset) instead of relying on auto-injection makes the system much more predictable — I can see exactly what's in my theme, no implicit magic. Migration was smooth too; that was the only thing I had to touch, and a CSS-diff check in my build confirmed the shipped output stayed consistent.

I also like the new optimize block — being able to tune removeUnusedTokens / removeUnusedKeyframes / smartCompoundVariants is great; I turned it on right away. Leaner CSS is always a win for Lighthouse scores.

I can't really speak to the speed gains — my projects are small enough that codegen was already fast, so I didn't notice a difference there. Happy to keep reporting anything else I hit as I move the rest over.

[mwisner]

Hi,

The migration docs around hooks are a bit confusing:

v1 hooks (cssgen:done, context:created, parser:after, config:change, and others) don't run in v2. Use optimize.removeUnusedTokens / removeUnusedKeyframes for unused theme CSS cleanup, or a PostCSS step after Panda for custom transforms.

does this mean that the concept of hooks are going away in panda v2, or just that these specific hooks are going away? we use the parser:before in our mixed chakra v2 and panda repos to avoid generating css for jsx props that use the same component name + prop as a panda component but aren't actually a panda component: #3437

[Adebesin-Cell]

Hooks aren't going away, only that specific set is. The ones that no longer run (cssgen:done, context:created, parser:after, config:change) were tied to the old JS pipeline, which is now the Rust engine. What v2 keeps: config:resolved, preset:resolved, parser:before, codegen: prepare, codegen:done.

parser:before is one we kept, so your mixed Chakra/Panda filter works unchanged in v2, it runs before extraction in both the native build and WASM/playground. A plugin that rewrites the non-Panda component out of the source stops its props from being extracted, exactly as before.

Separately, the false-positive extraction you're working around is on our beta tracking list, so you may be able to drop the hook entirely down the line.

[segunadebayo]

I've updated the migration guide to be clearer. Should clear up the confusion

[Adebesin-Cell]

Thanks! @segunadebayo

[amkige]

In v2, pattern property types appear to include a className prop. Is this intentional?

For example:

// styled-system/patterns/box.d.ts
export interface BoxProperties {
  className?: string
}

This prop doesn't exist in v1, and I couldn't find it mentioned in the v2 migration guide.

Additionally, passing className to a pattern generates a class like class-name_(value), which doesn't seem particularly useful.

It also causes type conflicts when composing React Aria components with a pattern, since React Aria uses a different type for className.

[segunadebayo]

Good catch! Must be an oversight

Update: Pushed a fix, will be out in the next beta

[finnan444]

v2 typing regression (since beta.3): cursor under strictTokens no longer accepts native CSS keywords

Versions: @pandacss/dev@2.0.0-beta.8 (regressed in beta.3), compared against 1.11.3.

With strictTokens: true + strictPropertyValues: true and no cursor tokens defined in the theme, the generated type for cursor changed:

// v1.11.3 — native keywords allowed
cursor?: ConditionalValue<WithEscapeHatch<CssProperties["cursor"]>>

// v2 beta.2 — loose
cursor?: ConditionalValue<CssValue>

// v2 beta.3 … beta.8 — keywords gone
cursor?: ConditionalValue<CursorValue>
// where CursorValue = WithEscapeHatch<Globals | TokenValue<"cursor"> | CssVars>

Since TokenValue<"cursor"> resolves to never when the token category is empty, the only accepted plain values are the CSS-wide globals (inherit | initial | revert | revert-layer | unset). Every real cursor value — default, pointer, grab, not-allowed, … — now requires the escape hatch:

cursor: 'pointer'    // ❌ type error in beta.3+, fine in v1
cursor: '[pointer]'  // ✅ forced workaround

Why this looks wrong

• Regression vs v1 under the identical config: v1 kept the native keyword set available even in strict mode.
• Inconsistent with strictPropertyValues semantics: cursor is a property with a finite set of predefined CSS values, so it behaves like display/position — and display: 'flex' still type-checks while cursor: 'pointer' does not.
• Expected: predefined keywords stay allowed (as for other strict-property-values properties), with cursor tokens added on top when defined.

Repro: minimal config with presets: ['@pandacss/preset-base'], strictTokens: true, strictPropertyValues: true, run panda codegen, inspect styled-system/types/system.d.ts.

[segunadebayo]

Fixed by @Adebesin-Cell. Will be included in the next release

[kris-ellery]

We're evaluating @pandacss/dev@2.0.0-beta.8 in a large design-system monorepo with a base component library, dependent packages, config wrappers, custom plugins, and several consuming applications. CSS generation is fast and produces output, but we found several gaps.

Build-info migration is unclear

The migration guide suggests replacing panda ship with panda buildinfo, but directly including the v2 artifact does not hydrate it:

include: ['./node_modules/@acme/design-system/dist/panda.buildinfo.json'];

Panda parses the JSON as JavaScript and reports js_parse_error.

The working path is panda lib plus:

designSystem: '@acme/design-system';

This contract appears in draft design notes but is not explained in the main migration guide.

Workspace peer ranges

With a workspace catalog dependency:

"@pandacss/dev": "catalog:"

panda lib writes this into panda.lib.json:

"panda": "catalog:"

Our current workaround is:

panda lib --panda 2.0.0-beta.8

It would help if Panda resolved workspace/catalog protocols or rejected invalid manifest ranges.

Nested design systems duplicate parent build info

For a chain like:

base design system → examples package → internal components → app

The design notes say each package should ship only its own extraction state, with consumers composing the artifacts. In beta.8, panda lib serializes already hydrated parents:

Package	Local atoms	panda lib atoms
Base design system	2,658	2,658
Examples package	119	2,737
Internal components	19	2,744

There is no apparent localOnly or exclusion option. --include limits scanned source files but does not exclude hydrated parent atoms.

Generated consumer types lose design-system tokens

CSS generation through designSystem succeeds with zero diagnostics, but generated consumer types do not include the parent token surface:

css({ backgroundColor: 'bg.neutral' });
// CSS is generated, but TypeScript reports TS2322

This affects semantic colors, spacing, typography, borders, and other design-system tokens. It may relate to the unfinished overlay/type-generation work mentioned in the design notes.

minify documentation/type mismatch

The migration guide shows top-level minify, and the CLI runs configs containing it, but beta.8's Config type rejects it:

'minify' does not exist in type 'Config'

Build-info schema mismatch

Beta.8 emits build-info schema version 3, while the current build-info design note documents schema version 2.

Final-CSS hooks

Removing cssgen:done also removes a useful integration point for reporting and analytics over final generated CSS. PostCSS covers some cases, but design systems often hide Panda behind a config wrapper and cannot require every consumer to control its PostCSS configuration.

Overall, the compiler and CSS-generation performance look promising. The largest blockers for our evaluation are package-local build-info composition and missing consumer token types. Clarifying the canonical library migration path in V2_MIGRATION.md would also help considerably.

[segunadebayo]

Thanks for this detailed feedback. We'll get to those and document the migration path for design systems.

Regarding the cssgen:done hook, we'll consider adding a migration guide or bringing it back.

[segunadebayo]

Update: We brought back the cssgen:done hook in 2.0.0-beta.9.

Feel free to share any more feedback after trying it.

[zachbwh-secure-fresha]

Sharing a distinct bug we hit while evaluating v2 (2.0.0-beta.9) that I couldn't find mentioned above:

Custom utility transform is ignored inside cva/sva recipes — Panda emits the kebab-cased utility key as the property instead of the transform's output. It works correctly in atomic css(), so the divergence is specific to the recipe code path. It fails silently (the resulting color-variable: … is an invalid property the browser drops; the intended custom property is never set).

Minimal repro:

// panda.config.ts
import { defineConfig } from '@pandacss/dev'
export default defineConfig({
  presets: ['@pandacss/preset-base'],
  include: ['./src/**/*.{ts,tsx}'],
  outdir: 'styled-system',
  theme: { extend: { tokens: { colors: { red: { value: '#f00' }, blue: { value: '#00f' }, green: { value: '#0f0' } } } } },
  utilities: {
    extend: {
      colorVariable: {
        shorthand: 'colorVar',
        className: '--color-var',
        values: 'colors',
        transform: (value) => ({ '--color-var': value }),
      },
    },
  },
})

// src/viaCss.ts
import { css } from '../styled-system/css'
export const a = css({ colorVar: 'red' })
// src/viaCva.ts
import { cva } from '../styled-system/css'
export const b = cva({ base: { colorVar: 'blue' } })
// src/viaSva.ts
import { sva } from '../styled-system/css'
export const c = sva({ slots: ['root'], base: { root: { colorVar: 'green' } } })

panda cssgen output (distinct values per usage so atomic dedup doesn't let the correct css() output mask the recipe output):

--color-var: var(--colors-red);        /* css()  ✅ transform applied */
color-variable: var(--colors-blue);    /* cva()  ❌ transform ignored, kebab key */
color-variable: var(--colors-green);   /* sva()  ❌ */

This also breaks preset-base's own shadowColor (transform: createColorMixTransform("--shadow-color")): inside a recipe, shadowColor: 'red' emits box-shadow-color: … instead of --shadow-color: …, so every var(--shadow-color) consumer silently breaks. So it affects the default preset, not just user-defined utilities.

Impact for us: design-system components define CSS-variable utilities via transform and use them in cva/sva, so this silently broke component padding, theming, and a focus ring with no build error. Confirmed on both cva and sva.

[segunadebayo]

Good catch! I pushed a detailed fix for this yesterday.

Look out for the next release.

[zachbwh-secure-fresha]

🐛 v2 ESLint/oxlint plugin (/oxlint) can't load against any config using @pandacss/preset-base — Native project does not support pattern.transform callbacks

While evaluating the beta on a real design system, I hit a blocker configuring the rebuilt lint plugin per the Linting migration steps.

Environment: @pandacss/eslint-plugin@2.0.0-beta.11, @pandacss/compiler@2.0.0-beta.11, oxlint@1.68.0, node 24, darwin-arm64.

Summary: The v2 oxlint plugin throws at plugin-load time for any config containing a pattern with a transform callback. That includes preset-base's own built-in patterns (stack, circle, grid, …), so it fails against essentially every real project. Because it fails during plugin registration, it takes down the entire oxlint run, not just the @pandacss/* rules.

Minimal repro (bare preset-base, nothing custom)

panda.config.ts

import { defineConfig } from '@pandacss/dev'

export default defineConfig({
  preflight: false,
  presets: ['@pandacss/preset-base'],
  include: ['src/**/*.{ts,tsx}'],
  outdir: 'styled-system',
  jsxFramework: 'react',
})

.oxlintrc.json

{
  "plugins": ["typescript"],
  "jsPlugins": [{ "name": "@pandacss", "specifier": "@pandacss/eslint-plugin/oxlint" }],
  "rules": { "@pandacss/no-invalid-nesting": "error" }
}

panda codegen && oxlint src/

x Failed to load JS plugin: @pandacss/eslint-plugin/oxlint
|   Error: Native project does not support pattern.transform callbacks
|     at registerCallbacks (@pandacss/compiler/dist/tooling/index.js:266)
|     at createCompilerFromSnapshot (@pandacss/compiler/dist/tooling/index.js:707)
|     at createProjectFromLoadedConfig (@pandacss/compiler/dist/tooling/index.js:811)
|     at loadPandaProject (@pandacss/eslint-plugin/dist/chunk-*.js:1116)

Root cause (from the compiler dist)

The plugin builds its project via createCompilerFromSnapshot (the portable buildinfo path). The shared registerCallbacks routine then tries to re-attach the pattern-transform callbacks, but the snapshot-restored native project doesn't implement registerPatternTransform, so it throws:

// @pandacss/compiler/dist/tooling/index.js
if (hasPatternTransforms && !project.registerPatternTransform) {
  throw new Error("Native project does not support pattern.transform callbacks");
}
if (project.registerPatternTransform && patternTransforms) {   // <- dead branch on the snapshot path
  for (const [id, callback] of Object.entries(patternTransforms)) {
    project.registerPatternTransform(id, /* ... */);
  }
}

This is understandable: a pattern transform is an arbitrary JS callback that can't be serialized into a portable snapshot, so it has to be re-attached at load time — and that re-attach binding just isn't wired up on the snapshot project yet. The method is even typed optional (registerPatternTransform?(…): void in types-*.d.ts), and registerUtilityTransform has the same guard right after it.

Note the full engine is unaffected — codegen/cssgen run these same pattern transforms fine. It's specific to the snapshot/tooling path the lint plugin uses.

Impact / notes

• Blocks the v2 oxlint plugin for any config that pulls in preset-base (i.e. the common case).
• The . (flat-config) entry isn't an oxlint fallback — oxlint can't register it (TypeError: Cannot convert undefined or null to object in registerPlugin); /oxlint is the only oxlint-compatible entry.
• Likely a small fix: expose registerPatternTransform (and registerUtilityTransform) on the snapshot-restored native project so the existing re-attach branch can run.

Happy to test a patch against the real design system if that's useful. 🙏

[segunadebayo]

The fix for this is now merged. Will publish a new version later today.

[zachbwh-secure-fresha]

patiently waiting for the new beta release :)

[finnan444]

panda codegen emits duplicate type aliases in system.d.ts — breaks objectPosition / backgroundPosition under strictTokens

Version: @pandacss/dev@2.0.0-beta.11 + @pandacss/preset-base@2.0.0-beta.11 (compared against 1.11.5)

codegen writes two export type declarations with the same name into the same file. TypeScript silently binds the first one, so several properties get the wrong value type.

Config — nothing exotic, reproduces on the bare minimum:

export default defineConfig({
    presets: ['@pandacss/preset-base'],
    strictTokens: true,
    strictPropertyValues: true,
})

Generated styled-system/types/system.d.ts:

// line 465 — for the CSS `position` property. This is the one TS binds.
export type PositionValue = WithEscapeHatch<PropertyValueMap["position"]>

// line 649 — the one that's correct for object-position / background-position. Shadowed, dead.
export type PositionValue = LengthValue | "bottom" | "center" | "left" | "right" | "top"

Both ContainerValue (lines 131 / 269) and ZIndexValue (589 / 657) collide the same way, so it isn't a one-off.

Symptom. PropertyValueMap maps a whole group of properties onto PositionValue:

backgroundPosition: PositionValue
maskPosition: PositionValue
objectPosition: PositionValue
offsetAnchor: PositionValue
offsetPosition: PositionValue
perspectiveOrigin: PositionValue
scrollSnapDestination: PositionValue

All of them now accept only static | relative | absolute | fixed | sticky:

css({ objectPosition: 'center' })            // ❌ TS2769
css({ objectPosition: 'top 0 right 25%' })   // ❌ TS2769
css({ backgroundPosition: 'center' })        // ❌ TS2769
css({ position: 'relative' })                // ✅ (winning alias happens to be the right one here)
css({ objectPosition: '[center]' })          // ✅ forced escape-hatch workaround

src/repro.ts(3,7): error TS2769: No overload matches this call.
    Type '"center"' is not assignable to type 'ConditionalValue<PositionValue> | undefined'.

Why it doesn't show up as a duplicate-identifier error. skipLibCheck: true — the default in astro/tsconfigs/strict and common elsewhere — suppresses the diagnostic inside .d.ts, but the binder still picks one declaration. With skipLibCheck: false it's explicit:

system.d.ts(465,13): error TS2300: Duplicate identifier 'PositionValue'.
system.d.ts(649,13): error TS2300: Duplicate identifier 'PositionValue'.
system.d.ts(131,13): error TS2300: Duplicate identifier 'ContainerValue'.
system.d.ts(269,13): error TS2300: Duplicate identifier 'ContainerValue'.
system.d.ts(589,13): error TS2300: Duplicate identifier 'ZIndexValue'.
system.d.ts(657,13): error TS2300: Duplicate identifier 'ZIndexValue'.

Note that without the strict flags the bug is invisible but still present: the winning PositionValue includes AnyString, so wrong values type-check by accident.

BEFORE / AFTER (codegen). v1 didn't route these through a named alias at all, and had no collision:

// v1.11.5 — styled-system/types/style-props.d.ts
objectPosition?: ConditionalValue<WithEscapeHatch<CssProperties["objectPosition"]>>

// v2.0.0-beta.11 — styled-system/types/system.d.ts
objectPosition?: ConditionalValue<ObjectPositionValue>   // → PropertyValueMap["objectPosition"] → wrong PositionValue

The same four css() calls above type-check cleanly on 1.11.5 (0 errors, and 0 TS2300 even with skipLibCheck: false).

One more variant of the same root cause. In a real project (custom preset on top of preset-base) the ZIndexValue collision came out as ZIndexValue = PropertyValueMap["zIndex"], which is self-referential, so it degrades to any rather than to something too narrow:

system.d.ts(627,13): error TS2456: Type alias 'ZIndexValue' circularly references itself.
system.d.ts(963,3): error TS2502: 'zIndex' is referenced directly or indirectly in its own type annotation.

I didn't manage to reduce that one to the minimal config, so treat the exact trigger as unconfirmed — but it looks like the same missing dedup in alias emission.

Expected: alias names are deduplicated (or namespaced per source), so objectPosition / backgroundPosition keep their position value type and no .d.ts ships duplicate identifiers.

[segunadebayo]

Fixed and merged on v2 (8ccb118). It'll be in the next @pandacss/dev@beta.

[zachbwh-secure-fresha]

Will there be a beta.12 release with the latest fixes? I'd love to try them out

[segunadebayo]

It's now released.

[zachbwh-secure-fresha]

Thank you so much! Testing now :)

[zachbwh-secure-fresha]

beta.12: keyframes is never emitted as a token category, so animationName rejects every keyframe name

Keyframe names have to be written as animationName: '[myKeyframe]' under strictTokens. They typed fine unbracketed on v1, and I couldn't find a config that restores that.

Environment: @pandacss/dev@2.0.0-beta.12, strictTokens: true, strictPropertyValues: true, node 24.

The generated type references a keyframes token category:

// styled-system/types/system.d.ts
type KeyframesValue = WithEscapeHatch<CssGlobals | TokenValue<"keyframes"> | CssVars>

keyframes is absent from the generated Tokens interface, and TokenValue maps a missing key to never:

// styled-system/types/tokens.d.ts
export type TokenValue<T extends string> = T extends keyof Tokens ? Tokens[T] : never

export interface Tokens {
  // aspectRatios, blurs, borderWidths, breakpoints, colors, durations, easings,
  // opacity, radii, shadows, sizes, spacing — no `keyframes`
}

That makes TokenValue<"keyframes"> resolve to never, leaving CssGlobals | CssVars as the only non-escape-hatch options:

css({ animationName: 'probeKf' })
//                   ^ '"probeKf"' is not assignable to type 'ConditionalValue<KeyframesValue> | undefined'
css({ animationName: '[probeKf]' })   // only this works

Repro

// panda.config.ts
export default defineConfig({
  preflight: false,
  presets: ['@pandacss/preset-base'],
  include: ['src/**/*.{ts,tsx}'],
  outdir: 'styled-system',
  strictTokens: true,
  theme: { extend: { keyframes: { probeKf: { from: { opacity: 0 }, to: { opacity: 1 } } } } },
})

Ruled out:

• theme.keyframes instead of theme.extend.keyframes. keyframes is missing from Tokens either way.
• strictPropertyValues: false. No effect.
• CSS emission. The @keyframes block is still generated and the animations run; only the types are affected.

For reference, v1 inlined the names: animationName: "beat" | "spinnerRotate" | "spinnerResize" | ….

This affects every animated component in our library.