Confusion about the StyleX CLI and sourcemaps

[zaydek]

I got the StyleX CLI working, but there's one thing I'm confused about. My understanding is that the CLI wants to take an input directory, apply all the StyleX preprocessing, and then emit a target output directory. But when you emit the output directory, there's no sourcemap, so now the lgos and errors will show you the .js file as opposed to the original .tsx file, and the LOC will often be the wrong one because of inconsistencies with whitespace, formatting, etc. Am I missing something? This doesn't seem optimal for debugging code.

I did review https://github.com/facebook/stylex/blob/main/packages/cli/src/options.js and https://babeljs.io/docs/babel-preset-typescript and so far haven't worked out if there's a way to get this behavior by looking more closely at the Babel plugins the CLI invokes. Does the CLI support sourcemaps or something like sourcemaps so you can know the original file and LOC logs and errors are being emitted from?

Here's the configuration file I'm using

// https://github.com/nmn/next-15-with-stylex-cli/blob/main/.stylex.json5

{
  input: ["./src"],
  output: ["./out"],
  cssBundleName: "stylex_bundle.css",
  useCSSLayers: true,
  babelPresets: [
    ["@babel/preset-typescript", { allExtensions: true, isTSX: true }],
    // "@babel/preset-react",
  ],
  // watch: true,
}

Thanks!

[zaydek]

For what it's worth, I came up with a workaround using sbuild with a custom StyleX plugin that invokes Babel under the hood and surprisingly it works. I haven't tested this thoroughly, but I did use Grok 3 to generate an architecture document to help me how this, help me remember how this works in the future: https://gist.github.com/zaydek/a735433b0a10100ff5675227f46a85f3.

[zaydek]

Will close this for now. That being said, I would be interested to see if the StyleX CLI emits source maps in the future. Will tag @Jta26.

[nmn]

You're right that the CLI is not great for debugging if you want to see the original code. The thinking is that by generating a folder of files with StyleX transformed away, you can debug by looking at those files instead.

In many cases this should also help demystify what StyleX is being transformed into which can help debug styling issues.

[zaydek]

Fair enough @nmn. I wasn't sure if it was just that I was omitting a CLI flag but it seemed intentional I'm glad to confirm I wasn't misusing the tool and is simply an omitted feature. My use case is setting up StyleX/React Compiler for a Chrome extension and I wanted to understand all the moving parts and roll my own solution instead of using something like Vite where it may come up short for a niche use case like Chrome extensions, Figma plugins, etc.

I dumbly implemented my own esbuild plugin then later remembered there's an official one and that works great. Turns out the React Compiler also "just works" because it's listed in my babel.config.js which in turn is respected because I take it the esbuild StyleX plugin imports the Babel config. That was a nice surprise. For reference, this is what I ended up doing:

The logging code is not strictly necessary just a nice to have.

https://gist.github.com/zaydek/818101ae01d900600dfdbee8f7657f57

And the Babel code is really simple:

// babel.config.js
module.exports = {
  // Add support for React Compiler
  // https://react.dev/learn/react-compiler
  plugins: ["react-compiler"],
  //// presets: [["@babel/preset-react", { runtime: "automatic" }]],
};

Anyway I was really delighted this worked out. I was a little anxious to work out how to implement a custom StyleX dev server thing but this turned out to be great. If anyone stumbles upon this, when I was going about it on my own I ended up here, which technically does work as well it's just more convoluted than it needed to be: https://gist.github.com/zaydek/a735433b0a10100ff5675227f46a85f3, which is also linked to above.