Closed sambecker closed 9 months ago
Hmm… clear cache maybe? Perhaps where you’re writing this is resolving to an older version? Eg clsx@2.0 within a workspace
It was on a project which did not have a prior version of clsx
. Tried removing the lock file and deleting node_modules
. Will try clearing the cache next!
Oh. Play with your tsconfig settings for module/moduleResolution. Only certain combos respect the exports map
Changing "moduleResolution": "node"
to "moduleResolution": "bundler"
in tsconfig.json
worked for me but that caused some other TS issues I had to resolve in my project.
Switching to "moduleResolution": "Bundler"
worked for me—thx for the tip @EvHaus!
Closing as this is a TypeScript (tsconfig
) setting, answered above.
Changing the moduleResolution is not an option when using nextjs.
The following mandatory changes were made to your tsconfig.json:
- moduleResolution was set to node (to match webpack resolution)
The value get's set back to node when changed to "Bundler"
Gotta love it... In such case @VinitSarvade, you can/should just use clsx
since the size difference is effectively nothing. The __intertop
helpers your Next config will inject into your output are larger than clsx
itself, let alone the difference between clsx/lite
and clsx.
If you really want to use clsx/lite
here, you can set up a "path alias" or "resolve alias" within Next.js config which will map clsx
to clsx/lite
at build time. However, since you'd still be using clsx
imports, typescript will use/follow the dts for clsx
Thank you for the explanation @lukeed. I like the idea of path alias, but like you mentioned the difference is not really much. The larger goal was mostly to ensure a uniform string arguments only option.
Excited to try out the new
lite
approach:But I'm running into a TypeScript import error:
Is there something I'm doing wrong? Installed
clsx 2.1.0
viapnpm 8.12.1