Error caused by `exports` field in `package.json`
milovangudelj opened this issue · comments
Describe the bug
Using the latest version of the package (v2.0.4
) along with esbuild and Next.js v13 this error pops up in the console when trying to import any icon from the library.
Package path . is not exported from package /my_pc_project_path/node_modules/@phosphor-icons/react (see exports field in /my_pc_project_path/node_modules/@phosphor-icons/react/package.json)
Looking up the path reported I can see this entry
// other stuff...
"exports": {
".": {
"import": "./dist/index.es.js"
}
},
// more stuff...
To Reproduce
It is quite the hassle, it invlolves setting up a monorepo with Turborepo and creating different apps and packages. If necessary I can provide a link to my repository.
Expected behavior
I expect the app to work without throwing any errors both in developement and production.
Desktop:
- OS: Fedora Linux 36 (Workstation Edition)
- Browser: Brave
- Version: Version 1.48.164 Chromium: 110.0.5481.100 (Official Build) (64-bit)
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?
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.
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.
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.
Transferring issue to @phosphor-icons/react
, since it pertains to this library only.
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 🤣
Glad to hear you got it resolved. It sounds like the issue is actually that we don't provide a CJS export anymore 😟
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?
Any solution?(
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.
I use js. Instead of ts config, i added in jsconfig
This solution didn't work for me(
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
istsconfig.json
with"allowJs"
attribute set totrue
.
So you should still be able to declare this in there
"module": "nodenext",
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..
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.
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 🤔
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.
Yeah definitely. I appreciate the help!
I'll update in this thread if a receive an answer tomorrow from the Sanity team.
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
I also recommend using the fully qualified path if you're doing modular imports (@phosphor-icons/react/dist/icons/Foo)
@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!
Any other issues here, or safe to close?
Everything is all good for me. Seems like the original issue is resolved as well @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.