[RFC] Better support for Variables, Mono-repos and PNPM

[nmn]

Problem

One of the challenging parts of using StyleX today is importing VarGroups from .stylex.js files. There are three details that are less than ideal:

1. We require a rootDir to be set in the Babel configuration should match the root directory of the project.
2. If you're using a package manager like PNPM, any variables defined by an NPM package is external to your project entirely. This means the path to the variable file relative to the rootDir is different on different machines. Making the built artifacts less portable.
3. We rely on Node's require.resolve so custom @/foo.stylex.js imports set up by frameworks like Next don't work.

Proposal

The idea is to remove the requirement for rootDir and instead rely on package.json files.
When importing a file, we would resolve the file being imported, walk up the directory path until we find a package.json file and then use the <package-name>/<path-to-file-within> as the key to hash to generate variable names. This will be used both for defining and exporting, and when importing variables. (We don't need to read the file itself. Just the file path)

This should solve problem 1 and 2 mentioned above. All files within your own project would walk up to to the nearest package.json file and have a consistent hash. All files in NPM packages would walk up to their own package.json file and also have consistent hashes. The hashes won't change regardless of whether the node_modules are actually local or just links to a global cache.

Possible Pitfall

This proposal makes two assumptions:

1. That every single file that might use StyleX is in a directory with a package.json file.
2. The package name in each package.json file is unique.

Solving Aliases

We could accept a simple object of aliases to rename imports before trying to resolve them in the Babel plugin. We can later figure out how to read the Next.js configuration and set this automatically in the NextJS plugin.

[rayan1810]

Hey @nmn, your proposed solutions should work in real-world scenarios, and just walking up the directory path should not hamper the build time too. Also, I'm pretty close to fixing the aliases issue. And if we can pass the config for aliases from the plugin options for now, I think I might be able to share a PR for this fix tomorrow 🤞.

[nmn]

and just walking up the directory path should not hamper the build time too

This is one of my bigger concerns and I'm unsure if it makes sense to use the synchronous or asynchronous File APIs for this.

[rayan1810]

What if we send the path details of all the package.json files while initiating the Babel plugin inside the nextjs plugin? This way when resolving each file we can write an algo for matching its path to the immediate package.json file path.

[nmn]

This can be a good optimisation, but we'd still need to do the resolving within Babel itself as a fallback.

[airtonix]

I'd like to throw a spanner in here by considering how stylex would work with nextjs in an nxdev monorepo.

packages in an nxdev monorepo:

https://github.com/airtonix/nx-stylex-issues/tree/master

• can be resolved purely by the repos root tsconfig path alias, and thus such a package most likely wont have it's own package.json
• can be resolved as a side effect of being handled by yarn/npm/pnpms workspace glob and thus will have a package.json
• be unbuildable, meaning other packages in the monorepo import untranspiled code
• be buildable, meaning other packages in the monorepo end up importing transpiled code

another spanner which may or may not affect your thinking is preconstruct.dev which ends up doing some kind of babel faking typescript shimming in local dev mode for packages.

[airtonix]

perhaps part of the api that the stylex plugin exposes would be a function that allows us to define how a file should be resolved.

[nmn]

We already have a PR for adding support for aliases which should solve this problem. It is also possible to use a Babel plugin that rewrites import before StyleX runs.

[paulm17]

Are these two issues related at all? #297

It's just I don't have any problems incorporating styleX in the appdir, nor in a packages folder with turborepo. However, when I am working with my own complex component library. No styles are generated for any components that are imported into the application and are running from the /dist folder (of the package).

This is even the case when using transpilepackages. I've tested Griffel, which seems fine and without needing transpilepackages. I just want to mention that. So you don't think it's a misconfiguration on my end. 😄

My question is this. On this issue and #297. When do you think these may be resolved? I understand that with the latter there maybe things outside of your control.

It's just that I'm using unocss right now. It doesn't scale for me. StyleX might seem like a way forward but I'd like to see these issues dealt with before I commit a lot of time doing a poc to see if I can migrate over.

Many thanks!

[nmn]

#297 is unrelated. We managed to make StyleX work with Webpack and Babel but as Next moves further towards being Rust-only, there may be issues. While we work on a long term solution, we're also working on a CLI which can be used as a separate pre-build before Next's build step to solve the same issue. This solution will have a slight build-time overhead but should work perfectly outside of that.

Now talking about this issue. This issue is specifically to improve how caching works. Even today, everything should build and work correctly, but when using PNPM, the exact variable names generated may be different on different machines, which hurts the ability to cache the results of compiling a file. Each build should be internally consistent though and should work correctly.

No styles are generated for any components that are imported into the application and are running from the /dist folder (of the package).

Currently we expect packages to be shipped uncompiled for them to work.