Atomic output order depends on file compilation order, and so is not deterministic

[etlovett]

Description

I'm considering using Panda for a large new project, as it supports many of the features I'm looking for: minimal runtime cost, atomic CSS output from CSS-in-JS object syntax input, RSC support, etc.

One of the other features I'd like to see in my CSS tooling is that CSS used in one component cannot affect the styling of another component (absent obvious loopholes like child and descendant combinators), but this is not the case in Panda. In particular, by mixing shorthand and longhand properties it's possible to construct cases where adding/removing CSS in one component changes the styling of another component.

In the playground I've constructed you can see an example of this with two components in the same file, but the same behavior could equally happen with two completely unrelated components, meaning that an engineer changing one part of a large codebase could inadvertently break the styling of some completely unrelated feature in another part of the codebase.

Is there a recommended solution here to avoid the risk of introducing bugs in other parts of the codebase? How have other users of Panda addressed this?

Thanks in advance for any insight you can provide!

Link to Reproduction

https://play.panda-css.com/ChaNc7V-5f

Steps to reproduce

1. Load the playground at https://play.panda-css.com/ChaNc7V-5f
2. Observe the height of the yellow square produced by SpacingComponent: 200px
3. Comment out the className prop on the App component's inner <div> (the one with the data-text prop)
4. See that the height of the yellow square has been reduced to 100px

Specifically this is because the ordering in the output CSS has changed: with all CSS in place the .pt_0px definition comes before the .p_100px definition, but after commenting out the className prop the .p_100px definition comes before the .pt_0px definition.

JS Framework

React, TS

Panda CSS Version

"@pandacss/dev": "0.30.1",

Browser

Any

Operating System

• macOS
• Windows
• Linux

Additional Information

No response

[segunadebayo]

The design of Panda is such that we won't have to rely on the css output order. Merging shorthand and longhand properties like this is one area we're looking to improve in Panda over time such that padding: 100px will be expanded to the longhand values padding(Top|Right|Bottom|Left).

In mean time, we intend to ship an ESLint rule "prefer-longhand-properties" that shows an error/warning when using shorthand like padding and margin in combination with shorthand like paddingTop

Panda uses a combination of smart merging techniques and cascade layer to ensure that we never have to rely on deterministic rule order.

A general rule of thumb is to always prefer the longhand css properties in most cases.

[etlovett]

The design of Panda is such that we won't have to rely on the css output order.

And I absolutely applaud the intent! My question is how (or whether) this goal is being met right now, in the presence of mixed shorthand and longhand properties.

In fact, I've discovered that it's not just about mixing shorthand and longhand in the same object in a nonsensical order; in https://play.panda-css.com/2RnpIGpd_x all padding* properties are written in a conceptually-valid ordering, but commenting out a className prop still results in incorrect resulting styling.

---

In mean time, we intend to ship an ESLint rule "prefer-longhand-properties" that shows an error/warning when using shorthand like padding and margin in combination with shorthand like paddingTop

Great! I agree that this should solve the issue. Do you have a sense of when you might be ready to ship this ESLint rule?

For what it's worth, if you wanted a solution that was more strongly enforced, I see two possible paths:

1. Have Panda's CSS generation fail when shorthand and longhand properties are mixed
2. Take inspiration from StyleX:
   1. Encode all shorthand and their corresponding longhand properties, and then each time Panda encounters a shorthand property it can drop any previous corresponding longhand properties since they're going to be ignored by the browser anyways.
   2. Encode all shorthand and longhand properties as priority layers and use CSS layers to deterministically allow any longhands not dropped in the previous step to override any shorthands.

The second is obviously a more graceful DX, but comes with additional implementation and maintenance cost.

[astahmer]

We will soon add an ESLint rule to prevent this kind of stuff (mixing long/shorthands).

We've also adopted the Linaria strategy so that shorthand property will always take precedence over the longhand property in this PR

[etlovett]

Great! That PR seems like a pretty complete solution on its own -- I'm not even sure an ESLint rule would be necessary with that landed, since the behavior then will be deterministic.

(The behavior can still be surprising, in that styles won't be applied in definition order, but eliminating the non-determinism is a huge step forward. The surprise I refer to comes from the following all producing the same result, when perhaps users would expect them not to: css({ padding: '8px', paddingTop: '4px' }), css({ paddingTop: '4px', padding: '8px' }), css({ padding: '8px' }, { paddingTop: '4px' }), css({ paddingTop: '4px' }, { padding: '8px' }).)

[anubra266]

@etlovett just released
https://github.com/chakra-ui/eslint-plugin-panda/blob/main/docs/rules/prefer-unified-property-style.md