Naman Goel

@nedjulius When the object is defined locally in the same file, that is allowed. You can also use `stylex.include` to spread styles from another file that have already been compiled...

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...

@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...

@rayan1810 I've given this problem some thought: https://github.com/facebook/stylex/discussions/111

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...

@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 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...

We use a different pattern to publish types where the type definition files shadow the source files. These files are regular Typescript code instead of declaration files. AFAIK, this has...

Thanks for the link @joshuajaco > When publishing a typed package to npm, it’s recommended to include a "types" field even if [extension substitution](https://www.typescriptlang.org/docs/handbook/modules/reference.html#file-extension-substitution) or [package.json "exports"](https://www.typescriptlang.org/docs/handbook/modules/reference.html#packagejson-exports) make it unnecessary,...

Thank you for your PR @kevintyj ! This change and more has been incorporated in a different PR that also adds ESM support, so I'm now closing this PR.