Error require of ES Module not supported

[MickL]

Since 9.x (I also tried 10.x and 11.x) when importing serialize-error:

import { serializeError } from 'serialize-error';

I get the following error:

Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/mick/git/myproject/node_modules/serialize-error/index.js from /Users/mick/myproject/src/myfile.ts not supported.
Instead change the require of index.js in /Users/myproject/myfile.ts to a dynamic import() which is available in all CommonJS modules.

It works when building with tsc but not when starting with ts-node. Any idea what this could be? I dont find any require() somewhere...

[sindresorhus]

https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

[MickL]

Hey @sindresorhus I dont know how this helps. I dont use any require() anywhere, I am on latest NodeJS.

This is reproducible using a blank NestJS project: npx @nestjs/cli new project-name and then adding serializer-error: npm i serialize-errror -S and simply adding it somewhere:

import { Injectable } from '@nestjs/common';
import { serializeError } from 'serialize-error';

@Injectable()
export class AppService {
  getHello(): string {
    serializeError({});
    return 'Hello World!';
  }
}

[papb]

Did you read the How can I make my TypeScript project output ESM section?

[MickL]

Yes I did read it twice. It happens even in a blank new NestJS project as shown above.

[MickL]

It is "weird" that I have more than 200 packages installed but serialize-error is the only one producing this error

[papb]

After re-reading your post and seeing this...

It works when building with tsc but not when starting with ts-node.

...and assuming you've already read this, I suggest you open an issue on ts-node or comment on this one

[papb]

Another idea: try to install and use another of Sindre's small ESM packages, such as alpha-sort, and see if they work. Maybe Sindre made a mistake when moving to ESM in this specific package? Since both packages are small, perhaps you can spot the issue yourself and send a PR.

[U-4-E-A]

I am having the same issue. Did you find a way to solve this? Thanks.

[MickL]

Actually I stayed on 8.1.

We have 5+ Nest / TypeScript projects with hundreds of dependencies and this is the only one making problems and as I wrote above it is easy to reproduce. If you find anything please post it here, thanks!

[U-4-E-A]

Actually I stayed on 8.1.

We have 5+ Nest / TypeScript projects with hundreds of dependencies and this is the only one making problems and as I wrote above it is easy to reproduce. If you find anything please post it here, thanks!

I've rolled back to 8.1 as well. I have also looked at the v11 repo and have started a process of converting it to my own module, possibly in Typescript. If I get any further along with that and have something functional, I will give you a shout. Given that the package is not updated very often, it might just be preferable to maintain my own repo as a copy of this one and check back here for updates from time to time.

[twosdai]

I have also rolled back to: "serialize-error": "^8.1.0" and this fixed the problem for me.

FWIW running:
"@nestjs/core": "^9.2.1",
Node: v14.21.2
"ts-node": "^10.0.0"

[MickL]

@sindresorhus could you please reopen as so many people are reporting the same issue?

[twosdai]

I fussed around with it more and the following statement works for me instead of the normal imports in 11.x for serialize-error

            const { serializeError } = await (eval(`import('serialize-error')`) as Promise<
                typeof import('serialize-error')
            >);

The more I've dug into this the more I'm leaning toward this not being a library specific issue. Rather its an issue within the JS community about handling ESM modules appropriately.

I got the idea for that bit of code from the following SO: https://stackoverflow.com/questions/70545129/compile-a-package-that-depends-on-esm-only-library-into-a-commonjs-package

While not elegant I have a feeling until TS-Node offers support for transpiling to ESM this won't be easily solved. Nor should we expect the library maintainer to fix it, since its not an issue with the library, rather the transpilation process from TS -> JS for ESM modules.

[papb]

@twosdai But if you're right, why would this be happening to serialize-error only?

Also, why use eval in your code? Why not simply const { serializeError } = await import('serialize-error')?

[twosdai]

@papb
The eval and string are necessary because TS will still transpile the code if: const { serializeError } = await import('serialize-error') is present. Which leads to the same ESM importing issue. In the SO comment I linked the post goes into it a bit deeper.

For as to why this module, in this place, in the specific point in time, localized in this specific repo. *shrug. Its an ESM module import issue for transpiling, I'm not sure if any of the other repo's that I've installed are actually using ESM modules and this is just the first one in a long line of breaking dependencies, or if there is a specific bug present in ts-node for transpilation.

As far as I can see between the diff of the 8.1.0 release to the current 11.0.0 release. There isn't anything obvious that is incorrect in the repo, and the only real change is exporting this as ESM. Which should be transpiled correctly but isn't. Leading me to believe that its an issue in ts-node's transpilation system. Which anecdotally (I don't have the GH issues on hand) has varying levels of support and completeness.

[NtTestAlert]

Like almost every sindresorhus/* package lately, this one also does not work with jest... Probably same problem.
And while I understand why and that it is not a problem with the lib itself, the bottomline for me sadly is I won't use it.

[papb]

since its not an issue with the library, rather the transpilation process from TS -> JS for ESM modules.

@twosdai Is there any issue open in TS for this?

[twosdai]

@papb TypeStrong/ts-node#1007
I believe this is the issue where they talk about the relative completeness of the feature, its still open and the discussion is still active which leads me to believe that its not fully complete.

EDIT:
Sorry didn't read that you meant for an open issue on TS itself. I don't believe there is (Or I cannot find it). The link I referenced for ts-node is because many of the developers in this thread used ts-node for the transpilation engine.

[Torrichel]

Having the same problem.
Downgrading to 8.1.0 helped.

"dependencies": {
"serialize-error": "8.1.0",
"@types/express": "^4.17.17",
"@types/jest": "^29.5.2",
"@types/node": "^20.1.0",
"jest": "^29.5.0",
"ts-jest": "^29.1.0",
"ts-node-dev": "^2.0.0",
"typescript": "^5.0.4"
}

[twosdai]

@Torrichel Did you try

            const { serializeError } = await (eval(`import('serialize-error')`) as Promise<
                typeof import('serialize-error')
            >);

for importing instead? just in case you want to keep the new version.

[crizo23]

@Torrichel Did you try

            const { serializeError } = await (eval(`import('serialize-error')`) as Promise<
                typeof import('serialize-error')
            >);

for importing instead? just in case you want to keep the new version.

oooh typescript. I tried this solution, then of course I got
SyntaxError: await is only valid in async functions and the top level bodies of modules

wrapped it in an async IIFE and got

Object.defineProperty(exports, "__esModule", { value: true });
                   
ReferenceError: exports is not defined in ES module scope