Richer debugging information that can power a dev-tools extension

[nmn]

We currently generate a unique className for every stylex.create call the identifies the file, constant name and rule name. We should have a more rich system for adding debugging information
that can then be used by a dev-tools extension.

What we would like is a list of all Style Objects applied with fileNames and line numbers, such as:

<div
  data-style-src="package-name:path/to/file:12,8-16-8; package-name:path/to/other:56,4-66,4"
  class="margin-xrjyskp padding-xkgsvji"
>

here the data-style-src attribute contains a list with the following information:

• The package name where the file can be found. (we should walk up to the nearest package.json file to find the name of the package)
• The relative path to within the package.
• The range where the Style object can be found (Starting line number and column number to the end)

All of this information should provide a future dev-tools extension to pull up the actual source for all the styles that are applied to an element in the order they are applied.

---

How it would need to work

It should be easy to find the needed metadata for this feature, but we would also need to find a way to attach the relevant metadata each compiled style rule.

• We need to be careful that this metadata is not included in the applied styles by stylex.props
• The compiler will need to inject the data-style-src attribute whenever {...stylex.props} is used.

Possible pitfalls

If the end developer uses stylex.props separately from the markup to then apply className and style manually, the compiler may not be able to reliably set the data- attribute.

We should have a separate lint rule that discourages this pattern.

---

Alt: Richer information in classNames

• We should improve the quality of the debug classNames as well.
• We should investigate if we can generate empty CSS rules for debug classNames with source maps in a way that achieves the same purpose.

[necolas]

We should have a more rich system for adding debugging information that can then be used by a dev-tools extension

FYI I also came across a Chrome extension that claims to improve StyleX debugging: https://github.com/astahmer/atomic-css-devtools.

we would also need to find a way to attach the relevant metadata each compiled style rule.

Maybe some of this needs to be built into styleq, since it's another type of merge across style objects. In StyleX, we can find soureMap file/line info like RSD does and add it to a compiled style as a specially-named prop (e.g., $$source). styleq can then concat the $$source values, include the result in the return value, and exclude the prop from the styles.

[nmn]

FYI I also came across a Chrome extension that claims to improve StyleX debugging: https://github.com/astahmer/atomic-css-devtools.

Yup I've seen it and installed it. It's a cleaner version of the "styles" panel, but it doesn't help track down the originating stylex.create calls. We could likely fork this extension add the specific capabilities we need though.

Maybe some of this needs to be built into styleq,

I've been thinking about this as well. I actually have styleq open right now! I want to ensure that this capability only adds a tiny amount of code to styleq because any changes to styleq would be shipped even in production. If this is not possible, we can just have a separate implementation only for dev.