I think I found my CLI issue

[BMCwebdev]

I was having an issue link to discussion with the CLI where it would keep telling me that I had defineVars that should have been compiled. While playing with https://github.com/Dwlad90/nextjs-app-dir-stylex I was getting the same errors. I think I found something. I'll just make a quick post about it, and follow up later as it is bedtime.

The issue seems to stem from having tokens in a stylex.js file that reference earlier tokens.

FYI, I am following the OpenProps example from StyleX

if I remove the tokens from the bottom that reference earlier tokens, the above mentioned plugin will work. I am going to try with the CLI tomorrow.

import { defineVars } from '@stylexjs/stylex';

export const colors = defineVars({
  teal_50: '#ccf1f5',
  teal_100: '#99e3eb',
  teal_200: '#66d6e0',
  teal_300: '#33c8d6',
  teal_400: '#1ac1d1',
  teal_500: '#00bacc',
  teal_600: '#00a7b8',
  teal_700: '#00828f',
  teal_800: '#005d66',
  teal_900: '#00383d',
  green_50: '#e3f5db',
  green_100: '#c7ebb7',
  green_200: '#abe092',
  green_300: '#8fd66e',
  green_400: '#81d15c',
  green_500: '#73cc4a',
  green_600: '#68b843',
  green_700: '#518f34',
  green_800: '#3a6625',
  green_900: '#233d16',
  yellow_50: '#fef2cc',
  yellow_100: '#fde699',
  yellow_200: '#fdd966',
  yellow_300: '#fccd33',
  yellow_400: '#fbc61a',
  yellow_500: '#fbc000',
  yellow_600: '#e2ad00',
  yellow_700: '#b08600',
  yellow_800: '#7e6000',
  yellow_900: '#4b3a00',
  red_50: '#fbcfd2',
  red_100: '#f79fa5',
  red_200: '#f27079',
  red_300: '#ee404c',
  red_400: '#ec2835',
  red_500: '#ea101f',
  red_600: '#d30e1c',
  red_700: '#a40b16',
  red_800: '#750810',
  red_900: '#460509',
});

export const colorsAlpha = defineVars({
  neutral_100: 'rgba(22, 22, 55, 0.03)',
  neutral_200: 'rgba(56, 39, 73, 0.06)',
  neutral_300: 'rgba(28, 0, 46, 0.11)',
  neutral_400: 'rgba(25, 5, 51, 0.16)',
  neutral_500: 'rgba(32, 10, 56, 0.22)',
  neutral_600: 'rgba(28, 7, 49, 0.27)'
});

export const colorsFeedback = defineVars({
  success: colors.green_500,
  warning: colors.yellow_500,
  critical: colors.red_500,
  info: colors.teal_500
});

[nmn]

This should be working. This is likely a CLI bug. Please report back with what you find out.

[BMCwebdev]

Nope, doesn't appear to be the issue. Following a thread with the developer of the SWC plugin, but it appears to be independent of StyleX.

Back to my CLI issue, I am still getting Error: 'stylex.defineVars' should never be called at runtime. It should be compiled away by '@stylexjs/babel-plugin'

Some other info from error consoles

⨯ node_modules/@stylexjs/stylex/lib/es/stylex.mjs (174:1) @ errorForFn
 ⨯ Error: 'stylex.defineVars' should never be called at runtime. It should be compiled away by '@stylexjs/babel-plugin'
    at __webpack_require__ (/Users/brian.mccarthy/Development/trashy/CLIDemo/.next/server/webpack-runtime.js:33:42)
    at eval (./src/app/page.js:11:93)
    at (rsc)/./src/app/page.js (/Users/brian.mccarthy/Development/trashy/CLIDemo/.next/server/app/page.js:173:1)
    at Function.__webpack_require__ (/Users/brian.mccarthy/Development/trashy/CLIDemo/.next/server/webpack-runtime.js:33:42)
    at async Promise.all (index 0)
digest: "4168016251"
  172 | styleq.factory = createStyleq;
  173 |
> 174 | const errorForFn = name => new Error(`'stylex.${name}' should never be called at runtime. It should be compiled away by '@stylexjs/babel-plugin'`);
      | ^
  175 | const errorForType = key => errorForFn(`types.${key}`);
  176 | function props() {
  177 |   const options = this;

I have set up a demo repo. https://github.com/BMCwebdev/CLIDemo

I took a copy of your CLI demo:
https://github.com/nmn/next-15-with-stylex-cli/tree/main

I install my token package, and tried using it in the page.tsx

My token repo: https://github.com/BMCwebdev/stylexAcmeNextTest/tree/main/packages/tokens
My token package: https://github.com/users/BMCwebdev/packages/npm/package/tokens

I will send you cookies if you take a peek!

Side question: I noticed that in your repo you have it set up somehow that I don't have to go through the whole rigamaroll to get watchman installed, which is great because my work computer (and moreso for my developers) is not so easy to install things like that (unsigned packages etc). Hopefully that is something I will be able to reproduce?

@nmn Thank you again. I have come to love StyleX so much, and I have a large group of developers I am excited to onboard and get them to fall in love too.

[nmn]

Thanks! Will investigate further.

[BMCwebdev]

Perhaps not helpful, but a little fyi: the SWC community plugin gives me the same error.

Both the SWC plugin and the CLI seem to not like my tokens (use of defineVars). Though the pattern is nearly identical to the open props demo. I am now using named variables instead of letting StyleX hash them, but I had the same issue back when I was letting StyleX hash them.

[nmn]

Variables depends on resolving file paths, so that might be part of the problem here. It's not currently the top priority, but I will be investigating this problem soon.

[BMCwebdev]

Okay, getting close here!

So I have the CLI working (and the SWC community plugin working) when I make a version of my token library with only 1 file. Something about my current setup breaks what StyleX must be expecting.

For example, if I import something from the package published by this repository, which only has one token file, everything works
https://github.com/BMCwebdev/stylexAcmeNextTest/tree/main/packages/tokens

But, if I import something from the package published by this repository, which has 2 token files, I will get the defineVars error.
https://github.com/BMCwebdev/stylexAcmeNextTest/tree/main/packages/tokens-double-different

There must be something about my setup (with two files) that is incorrect, but I'm not sure what StyleX doesn't like about it, or what the correct method should be.

But soooooo close now!

[BMCwebdev]

Hey @nmn and @Jta26 just wanted to give you both a ping on this one. I think I found something worth persuing. I have been trying to get the CLI to work for me for a while, and one wall I often hit is I will get an error saying that defineVars should be compiled away. This confused me because if I look in the compiled app folder, there are no calls for defineVars.

What I did discover however, is that the import for my token library stays behind. And I suppose even though the usage of the token library is no longer in the file (because it has all been compiled away) the import alone perhaps is trying to pull in another copy of the un-compiled token library?

Example of un-compiled and compiled file

// un-compiled
'use client';

import * as stylex from '@stylexjs/stylex';
import { coreTokens as $ } from '@bonterratech/stitch-tokens/coreTokens.stylex';

export const styles = stylex.create({
  banner: {
    color: $['--s-color-red-500']
  }
});

export default function Home() {
  return (
    <div {...stylex.props(styles.banner)}>hiagain</div>
  );
}

// compiled
'use client';

import "../../stylex_bundle.css";
import * as stylex from '@stylexjs/stylex';
import { coreTokens as $ } from '@bonterratech/stitch-tokens/coreTokens.stylex';
export const styles = {
  banner: {
    color: "x60dknu",
    $$css: true
  }
};
export default function Home() {
  return <div {...{
    className: "x60dknu"
  }}>hiagain</div>;
}

If I delete import { coreTokens as $ } from '@bonterratech/stitch-tokens/coreTokens.stylex'; from the compiled code, it works.

I don't think that is the only issue. That worked when I used a simplified version of my app. When I try to use the full app, even if I go through the compiled code and remove all of the instances of the above import I still get defineVars error. So there must be something else as well. But hopefully this is useful feedback for you.

[BMCwebdev]

Ah, just noticed a comment on the CLI that @ aliases are broken. That could be contributing to my issues, my larger application uses them.

Must they all be removed or is it only usage of aliases that touch StyleX code?

[nmn]

@Jta26 has noticed a few issues when using variables from other repositories. This is currently a known issue with the CLI.