-
Notifications
You must be signed in to change notification settings - Fork 90
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
Issue with ES module treatment in Next.js environment #147
Comments
Huh, I suppose this should get stripped on publish. |
I'm a little confused because I'm not able to reproduce the error you're seeing. Can you give a reproduction repo? A fresh Next.js installation works fine in dev and prod for me. In the meantime, I'll publish a version without |
Okay, 0.18.4 was published without |
Thank you so much, it's working now! In terms of reprod repo, I'll see what I can do to reproduce the error myself in a different project, but the project it was occurring in is https://github.com/PavlosDefoort/PhotoProX. Perhaps the issue may be in one of the next js config files. |
#163 #147 These issues are related. "type": "module" was removed but in our instance this actually causes issues for NextJS when trying to import (named imports specifically) from mafs, such as: ![image](https://github.com/user-attachments/assets/3704e279-cea0-4bc9-9fff-d7350657ec88) I think the correct solution should have been to keep "type": "module" and use the "cjs" extension for the CJS output. That fixes both our issues and those listed in the 2 issues above, removing the type module field and using .mjs unfortunately only solves the issue for CJS users, but not for ESM users. Even better is to just use package entrypoints so there is no confusion. Reason being that the "module" field next to the "main" field is an unspecced conventional field that only *some* tools respect, and "main" is technically a legacy field now. The future-proof method is package entrypoints, and has the benefit of locking down your public API, which means users won't accidentally rely on private API by using direct filepath imports. This gives the maintainer the freedom to structure the published files in any way they please without causing breaking changes. --------- Co-authored-by: Steven Petryk <petryk.steven@gmail.com>
Hello! I am currently having an issue when using the Mafs library with Next.js.
The issue appears to be that in
package.json
of this library the"type"
is set to"module"
. However, Next.js treats.js
files as CommonJS Modules which leads to compatibility issues. I have found a temporary fix in my development environment where I edit thepackage.json
to use CommonJS. However, in production, this doesn't work since thenode_modules
folder is typically not committed. I was wondering how Mafs is typically used with Next.js to fix these errors in production.The text was updated successfully, but these errors were encountered: