Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Importing a .stylex.ts does not work with tsconfig paths settings #40

Open
ethanjdiamond opened this issue Dec 6, 2023 · 12 comments · Fixed by #202
Open

Importing a .stylex.ts does not work with tsconfig paths settings #40

ethanjdiamond opened this issue Dec 6, 2023 · 12 comments · Fixed by #202
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@ethanjdiamond
Copy link

ethanjdiamond commented Dec 6, 2023

The problem
When importing a variable file like is listed in the docs, the build is only succeeding if the import path is a relative path (i.e. ../src/lib/theme/theme.stylex), but fails if the import path uses the tsconfig "paths" setting (i.e. @/lib/theme/theme.stylex when tsconfig paths is { '@/*' : '.src/*'} ).

With non-relative paths, it gives the Only static values are allowed inside of a stylex.create() call error message.

How to reproduce

Steps to reproduce:

  1. Create a next.js app with the default of paths: { '@/*' : '.src/*'} in the tsconfig.json file.
  2. Create a file called theme.stylex.ts in /src/lib/ that defines a color using export const colors = stylex.defineVars({test: '#000000'})
  3. Try to import the colors using import { colors } from @/lib/theme.stylex and use colors.test in a stylex.create call.

Expected behavior
I would expect this to allow colors to be used in stylex.create as specified in the docs.

Environment (include versions). Did this work in previous versions?

  • next 14.0.2 using an app router
  • @stylexjs/stylex - 0.3.0
  • @stylexjs/nextjs-plugin - 0.3.0
@rayan1810
Copy link
Contributor

rayan1810 commented Dec 6, 2023

If this support is not deliberately excluded, I would like to work on a PR to add this feature. @necolas

@nmn
Copy link
Contributor

nmn commented Dec 6, 2023

The StyleX Babel plugin relies on the require.resolve function to determine the absolute file path of the module being imported. If aliases are setup in a way that Node would understand, they would work. e.g. mono-repos.

@rayan1810 Happy for accept your contribution to solve this problem! Please start by describing an outline of how you would solve it. Here's the relevant code:

importPathResolver(importPath: string): ImportPathResolution {

@nmn nmn added the enhancement New feature or request label Dec 6, 2023
@rayan1810
Copy link
Contributor

I just did a POC, so if I check if it's a NextJS application and If it has aliases added in tsconfig.json or jsconfig.json. I can check for import paths that starts with "@" and resolve the path based on the aliasing received from tsconfig.json or jsconfig.json. Then this resolved path can be passed into the require.resolve.

@nmn
Copy link
Contributor

nmn commented Dec 6, 2023

@rayan1810 This solution feels too specific to Next and TS. Perhaps there is a way to pass in an alias configuration to the Babel plugin itself? Then, the Next.js plugin can read the aliases and inject them into the Babel plugin while using it.

@rayan1810
Copy link
Contributor

I agree @nmn, tested the flow with a POC and it works. Working on a PR for the same.

@nmn
Copy link
Contributor

nmn commented Dec 9, 2023

@rayan1810 I've given this problem some thought: #111

@AbhiPartha
Copy link

This issue seems to even happen for relative imports

For example you can use this repo to reproduce it.
https://github.com/millnut/storybook_foundations/tree/feature/stylex-support

Any idea why this could be happening ?
Node version: v18.18.2

@nmn
Copy link
Contributor

nmn commented Feb 7, 2024

A quick update is that StyleX can now be configured to resolve aliases, although the configuration requires absolute paths. See the Next example in the repo for an example.

@AbhiPartha Please don't post the same comment in multiple issues. I'll keep this one as it's on an open issue and delete the other one for now.

@AbhiPartha
Copy link

AbhiPartha commented Feb 7, 2024

I was able to make it work using @storybook/next in combination with stylex next plugin
https://github.com/AbhiPartha/StyleXComponentLibrary
Thanks for that !!

Although giving more info about the above issue, It says only if tsconfig paths are set and can leave devs thinking it works for relative imports, the error happens irrespective of setting tsconfig alias or not.

Error: Only static values are allowed inside of a stylex.create() call

@nmn
Copy link
Contributor

nmn commented Feb 8, 2024

@AbhiPartha yes. this is a known issue. The StyleX babel plugin can be configured to understand aliases. We don't automatically discover and read aliases defined in a tsconfig file.

@jderboven
Copy link

Any clues on how we could do it for a nx monorepo project with a lib containing styleX ?
I would like to make a shareable theming lib within my monorepo with variables and styles defined with stylex so I can be able to share tokens to all of my apps.

Actually getting the same issue but there are no relative paths here.

@nmn
Copy link
Contributor

nmn commented Feb 19, 2024

@jderboven Depends on the framework/bundler you're using. AFAIK, using nx should not change how it is configured.

Generally, you need to configure the build for your app to also compile the packages you're importing. These external packages may be from your mono-repo or node_modules. In Next.js, for example, you need to add the package names to transpilePackages key.

Vite has a similar option AFAIK. (Although, you'd need to delete the Vite cache between builds for things to work consistently.)

Actually getting the same issue but there are no relative paths here.

Could you explain what this means?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants