Error caused by `exports` field in `package.json`

[milovangudelj]

Error caused by `exports` field in `package.json`

[rektdeckard]

I've just published v2.0.8, which includes a UMD export (compatible with CJS build tooling), and does not specify "type": "module" in package.json. This should alleviate all of the build issues mentioned here. As a side-effect of the build, we won't support any qualified imports in that environment:

import AddressBook from "@phosphor-icons/react/AddressBook"; // CAN'T DO THIS IN CJS ENVIRONMENT
import { AddressBook } from "@phosphor-icons/react"; // CAN DO THIS IN EITHER ENVIRONMENT

[rylanharper]

@rektdeckard I just tested the latest update of @phosphor-icons/react with Sanity (latest version 3.8.2) and its working great! No issues are logged when deploying graphql or with importing icons into react templates!

[milovangudelj]

Ok, thank you. I will check again tomorrow to see if there's something I can change in the esbuild configuration and/or in my Turborepo setup and I'll let you know.

I'll link you my repo when I commit the changes since right now I have them locally on my machine.

[milovangudelj]

As I mentioned above that only works if you have set your package type to "module" instead of "commonjs" in your package.json file.

But this isn't possible for every type of application/package. Sanity requires you to use common js and switching is quite the hassle. I've tried doing that in the past with various degrees of success and you have to make compromises whichever way you chose to go.

[rylanharper]

Yeah definitely. I appreciate the help!

I'll update in this thread if a receive an answer tomorrow from the Sanity team.

[rylanharper]

Everything is all good for me. Seems like the original issue is resolved as well @milovangudelj?

[rektdeckard]

I'm not sure I understand. This is a valid exports field, and points to a valid file... This sounds like a Turborepo or esbuild bug to me?

[rektdeckard]

If you want to link me the repo I could take a look. I could remove this field altogether, since the module field is present in package.json and serves the same purpose, and we only have a single entrypoint. But there doesn't appear to be anything wrong about this. In order to make use of this field, you need node@^12 and typescript@^4.7, according to this SO post, but it should not be causing issues otherwise.

[rektdeckard]

Some digging shows that TS may need assistance with export maps in node versions <=14. I would try adding "moduleResolution": "Node16" or "NodeNext" in your tsconfig and/or making sure you are on a modern node version.

[rektdeckard]

Transferring issue to @phosphor-icons/react, since it pertains to this library only.

[milovangudelj]

Ok, so... I've checked and I'm using the latest version of both Typescript (v4.9.5) and Node.js (v18.1.0).

Previously I said I was using esbuild but I meant tsup, I guess I got confused since tsup uses esbuild under the hood.

I took me a while but I converted the package to type module form commonjs. This allowed me to add

"module": "nodenext",

in my tsconfig file which fixed the issue with the exports field in your package.

Removing the exports entry from the package.json present in the node_modules directory also fixed the issue but it wasn't an optimal solution. It would have had to be a change from your side and I don't know if this would break things for someone else just to fix a bug for me.

As a last note, if you want you can see the repo here. I'm transferring an old repository to a monorepo and upgrading to Next.js v13. The published site is this https://piscina.ilikemartians.com.

Shameless plug, I know 🤣

[rektdeckard]

Glad to hear you got it resolved. It sounds like the issue is actually that we don't provide a CJS export anymore 😟

[milovangudelj]

Out of curiosity, why is that? I mean, why don't you provide a CJS export anymore? Is it just a decision to move towards an ESM future or is there a technical issue that prevents you from being able to provide both?

[madly0894]

Any solution?(

[milovangudelj]

The solution rn is to convert your package type from commonjs to module in your package.json.

Once you do that you can then add

"module": "nodenext",

in your tsconfig file. This should fix the issue.

If for some reason you can't convert to a module type package you can remove the exports field from the library's package.json present in the node_modules directory, but that's just a temporary fix.

[madly0894]

I use js. Instead of ts config, i added in jsconfig
This solution didn't work for me(

[milovangudelj]

From VS Code's jsconfig.json reference page

Tip: jsconfig.json is a descendant of tsconfig.json, which is a configuration file for TypeScript. jsconfig.json is tsconfig.json with "allowJs" attribute set to true.

So you should still be able to declare this in there

"module": "nodenext",

[rylanharper]

Does anyone know what the solution for this is? I am also getting this issue when using the latest version of Phosphor Icons with Sanity. However everything works with the old phosphor-react library. It would be best not to downgrade though..

For instance, when trying to launch a simple graphql-deploy for my content schema I get the following error:

$ sanity graphql deploy

Error: Failed to load configuration file "/my_project_path/studio/sanity.config.js":
No "exports" main defined in /my_project_path/node_modules/@phosphor-icons/react/package.json

Would be great to see a simple solution for a javascript project (without typescript).

@milovangudelj does the "module": "nodenext" go in package.json? I haven't had to use this approach before..

[milovangudelj]

Nope, it goes either in your tsconfig.json or jsconfig.json file.

This is necessary if you're trying to use an ESM-only package, and @phosphor-icons/react became ESM-only after v2.

[rylanharper]

Hmm yeah that didn't work for me.. I may just post this issue on the Sanity forms tomorrow and see what the best approach is. I may just have to downgrade to the old version of Phosphor. Could be just my specific use case with Sanity 🤔

[rektdeckard]

I also recommend using the fully qualified path if you're doing modular imports (@phosphor-icons/react/dist/icons/Foo)

[rektdeckard]

Any other issues here, or safe to close?

[milovangudelj]

I haven't had the chance to try it out yet but judging from what I've read so far it seems resolved. I'll close the issue for now.

Feel free to reopen it if you find more errors related to this.