`no-dynamic-styling` false positives

[jaredkhan]

I'm seeing false positives on the no-dynamic-styling rule.

1. Negative numeric spacing values

These seem to be valid in Panda, at least they seem to work, and I think they're created by: https://github.com/chakra-ui/panda/blob/9453c9b8e5957b34efe9711c528a0d37b81025c0/packages/token-dictionary/src/middleware.ts#L6

but in their numeric form I get an error from the no-dynamic-styling rule.
The string form is allowed by the rule.

          <div
            className={css({
              display: "block",
              position: "absolute",
              left: -12,  // Would expect this to be allowed by `no-dynamic-styling`. "-12" works fine.
            })}
          />

2. Runtime conditions
   Maybe I'm missing the point on this one, but I would expect ternary expressions where the two branches are both statically analysable to also be allowed under this rule.
   https://panda-css.com/docs/guides/dynamic-styling#runtime-conditions
   I had expected the rule to match the 'What you can do' section of the dynamic-styling docs.
   But if that's not the intended behaviour, then perhaps this is a feature request for a rule that lets me catch the stuff that literally doesn't work (like passing user input directly into a panda call).

      <div
        className={css({
          height: isShort ? 6 : 12,  // Would expect this to be allowed by `no-dynamic-styling`
          width: 2,
        })}
      >

[anubra266]

Hello @jaredkhan

For no 1

...this behavior is expected and technically fine, and here’s why:

Panda supports negative numeric spacing values like -12 because the token middleware internally transforms numeric values into their token-equivalent string form (e.g., -12 → "-12"), as long as that token exists in your design system.

However, the no-dynamic-styling ESLint rule flags raw numbers (like -12) because it assumes any non-string literal is potentially dynamic and non-tokenized — which could lead to unstyled output in production builds if not handled carefully.

On the other hand, "-12" is a string token, so the rule allows it since it knows it maps to a valid value in the token dictionary.

Bottom line:

• ✅ "-12": Allowed, because it’s a known token string.
• ❌ -12: ESLint flags it as dynamic, even though Panda supports it, because ESLint doesn’t evaluate token middleware, and it might as well be -12 * 1.

So even though Panda can handle the numeric form, it’s safest (and ESLint-compliant) to use the string form for token-based spacing.

For no 2...

The ESLint rule no-dynamic-styling isn't trying to block what's technically valid in Panda — it's designed to prevent any form of runtime styling, even "safe" ones like static ternaries.

Looking at the rule’s own examples from the rule docs , it's clear:

• 🛑 const styles = css({ bg: color })
• 🛑 css({ padding: ['4', size] })
• 🛑 stack({ align: align })
• 🛑 styled.div color={color}
• 🛑 css({ [property]: 'red.100' })
• 🛑 Even cva({ variants: { [computedValue]: { ... } } })

All of these are blocked — not because they won’t work, but because they introduce indirection that makes styles harder to statically analyze or extract at build time.

So to answer your original point:

“I would expect ternary expressions where both branches are statically analysable to be allowed…”

That’s understandable — but not the rule’s goal. The rule exists to discourage runtime conditions altogether, not to selectively allow ones that happen to resolve safely. That way, you get guaranteed static extraction, predictable output, and simpler debugging.

In short:
✔ Panda might allow it.
❌ The ESLint rule won't — because its job is to enforce safe, fully static styling, not just valid code.