ky-universal: Error [ERR_REQUIRE_ESM]: Must use import to load ES Module
In Node.js v14, I got this error.
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/salty/Documents/src/youtu-bu/node_modules/ky-universal/index.js
require() of ES modules is not supported.
require() of /Users/salty/Documents/src/youtu-bu/node_modules/ky-universal/index.js from /Users/salty/Documents/src/youtu-bu/packages/youtu-bu-sakagura/.next/server/pages/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename /Users/salty/Documents/src/youtu-bu/node_modules/ky-universal/index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/salty/Documents/src/youtu-bu/node_modules/ky-universal/package.json.
Could you tell me why do you use "type": "module"
in package.json?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 5
- Comments: 27 (2 by maintainers)
I think you could have easily Googled the error and figured this out yourself.
It’s also explained in the release notes: https://github.com/sindresorhus/ky-universal/releases/tag/v0.9.0
@RXminuS I can understand the situation is annoying. Yes, I could have been more helpful in the issue comment, but I get many issues like this every day where the poster did zero effort in Googling or debugging stuff themselves. It’s both time consuming and demotivating.
ky-universal
is a 100% valid ESM package. The fact that Next.js cannot handle ESM is not really something I can control or something I should be obliged to answer support questions about. ESM has been in development for 10 years. We all knew it was coming. Webpack and Next.js could have better prepared for this. In the end, you are the one that chose to use Next.js, with all the hidden complexity that entails.That being said, I’m happy to document workarounds for Next.js in https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c (comment on that gist with any working workarounds)
@saltyshiomix Ky uses modern JavaScript features, including ES modules. We have
"type": "module"
in package.json to let Node.js and the rest of the ecosystem know that this is the case. To import Ky, you need toimport ky from 'ky'
instead ofconst ky = require('ky')
or whatever older syntax you may have been using previously. You should update your other imports to useimport
as well. It should work for older dependencies, too.If this doesn’t work for some reason, it would be good to have more details to understand what is going on.
If for some reason you continue to struggle with
import
, then I would recommend using an older version of Ky, such as 0.25.1 or below. Or if you’re usingky-universal
, then 0.8.2 or below. Those versions have a UMD build for older environments. But you should use it only as a last resort.This has pretty much made it unusable with Next.js, if anyone figured out a good workaround can you share here and I’ll make a PR in the docs.
And all due respect for maintaining a large library like this but that was a pretty shitty response @sindresorhus
Hi everyone. I think what’s happening to most of you is that you’re using a tool like Next.js which itself uses Webpack to compile your code and that system is converting your
import
statements torequire()
calls, which are incompatible with Ky.Please, if you’re using any system like that, be sure to ask them if they have a way to keep your
import
statements intact.Solved this issue by downgrading ky to: “ky”: “0.24.0”, “ky-universal”: “0.8.2” But I think maintainers should draw attention to this issue
I love when people say this and then their response becomes the top result for the issue on Google.
@DevelopedByDavid we don’t expect you to understand the internals of Ky. Equally, I hope you don’t expect us to understand Laravel or where exactly the friction is coming from in the Ky <–> Laravel relationship. I can make some educated guesses and point you to related technical resources but at the end of the day, I know nothing about how they’ve implemented Ky. Did they follow our instructions? Is their system mangling our import statements? I have no idea. This is why Sindre linked to the release notes, which link to this useful gist, which explains what Ky needs to be imported. That’s about the most help we can provide without seeing your code and having an understanding of the other technologies you are using.
I, for one, would be more than happy to dig in further and help research and debug the problem. But that requires a lot of time and effort, which won’t always be volunteered for free by every maintainer. Personally, I have no plans to learn Laravel at the moment. I’m available for hire if you specifically want a Ky maintainer to look into this. But what I would recommend instead is contacting the Laravel folks who integrated Ky, and ask them if they know what’s going on. It could be as simple as enabling a configuration option. If they don’t have a solution, then they should reach out to us and we can work together to create one by explaining what we need from each other. That will be vastly more efficient and you can help facilitate those conversations, regardless of your experience level.
I’m also getting this issue, I don’t know why… I’ve already updated my imports to
import ky from 'ky-universal'
, and updatedky
to version 0.26.0I use import statement in my code
But the error is related to source code from node-modules
How I can solve this issue without forking and fixing ‘ky’ library?
Some of us are not familiar with the inner workings of these massive libraries. I am using Laravel to gain a better understanding of the framework. Frameworks are designed to make things faster and easier. I was following along with a tutorial and making a project with what I am learning. Then I attempt to do what make:auth used to do and it ruined my project. now I am on attempt four. This time in accordance with Laravel docs I tried to install laravel/breeze. Now this project is ruined also as previously working views are now throwing 404. Makes no sense to me. I read a bunch of the comments on this issue and even that isn’t a solution for someone like me because all of them require me to understand node or other technologies that I didn’t ‘choose’ to use. Laravel used to work fine for me when I first learned but now it seems broken. Youre not obligated to fix the issues you find beneath your time and consideration. Your asshole attitude is the issue. Lucky for you you have a solid understanding of these issues. For the beginners, you ‘demotivate’ them to continue to learn. You clearly have a wealth of knowledge. Wouldn’t it be nice to have a good mentor to guide us along to get where you are. Since you get the issue daily and seemingly have the time to spew shit at others, why dont you create the step by step to fix the issue and post it instead. He did google it, just like I did. Guess where Google brought me for an answer? To your condescending reply that offers no real insight. It isnt because you waste time each day or you would just post the link to guide them to the answer. you feel the need to put others down. fuck you.
Try adding “allowSyntheticDefaultImports”: true, to tsconfig.json
It works but it’s not elegant, you would need to store it in a ref or a state to share it across different callbacks in the same React component. Or import it inside each one.
Importing it at top level doesn’t work:
Btw, I think you need to get the default export: