CSS order when use css() with classNames

[pedronauck]

Bug report

Describe the bug

I'm trying to customize a component that is applying css() as className and also has the possibility to add a className via props, but the order className is applied is not right. Idk, but it seems that stitches is adding generated styles into the stylesheet in the wrong order.

Code

import { createStitches } from "@stitches/react";
import cx from "classnames";

const { css } = createStitches();

const styles = {
  button: css({
    variants: {
      foo: {
        true: {
          backgroundColor: "red"
        }
      }
    }
  }),
  custom: css({
    backgroundColor: "yellow"
  })
};

function Button(props) {
  return (
    <button className={cx(props.className, styles.button({ foo: props.foo }))}>
      {props.children}
    </button>
  );
}

export default function App() {
  return (
    <Button className={styles.custom()} foo>
      Click
    </Button>
  );
}

To Reproduce

You can see the wrong behavior here: https://codesandbox.io/s/flamboyant-curran-1sbzop?file=/src/App.js

Expected behavior

The button inside the Codesandbox should be yellow.

[hadihallak]

We're working on a fix for this and it will be part of the 2.0 release. No ETA currently as it's a very big change involving a re-write of a big chunk of the internals

[samuelpetroline]

@hadihallak is there any workaround in the meantine?

[idrm]

It seems that Stitches groups the CSS classes it generates into different 'bundles', and the variant class rule bundle is injected after the non-variant one. This results in the variant classes overriding the non-variant ones.

Here's what the rules look like in @pedronauck's example and why the background ends up being red:

Ultimately, Stitches needs to provide a way to control the CSS precedence of its generated classes so that there are no uncertainties as to which underlying styles apply (e.g. by letting the dev assign a customizable injection level to each class generated by styled and css; this may still leave the precedence rules within the same level indeterministic/ambiguous).

Perhaps, that's one of the features on the ver.2 roadmap.