Skip to content
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

Closed
PavlosDefoort opened this issue Mar 23, 2024 · 4 comments
Closed

Issue with ES module treatment in Next.js environment #147

PavlosDefoort opened this issue Mar 23, 2024 · 4 comments

Comments

@PavlosDefoort
Copy link

PavlosDefoort commented Mar 23, 2024

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 the package.json to use CommonJS. However, in production, this doesn't work since the node_modules folder is typically not committed. I was wondering how Mafs is typically used with Next.js to fix these errors in production.

image
@stevenpetryk
Copy link
Owner

Huh, I suppose this should get stripped on publish.

@stevenpetryk
Copy link
Owner

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 "type": "module" since it's not really needed.

@stevenpetryk
Copy link
Owner

Okay, 0.18.4 was published without "type": "module"—give it a whirl. I'll close this issue but let me know if you're still encountering issues.

@PavlosDefoort
Copy link
Author

Okay, 0.18.4 was published without "type": "module"—give it a whirl. I'll close this issue but let me know if you're still encountering issues.

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.

stevenpetryk added a commit that referenced this issue Oct 14, 2024
#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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants