Error [ERR_REQUIRE_ESM]

Question

Error [ERR_REQUIRE_ESM]

anthonny opened this issue 2 years ago · comments

Anthonny Quérouil commented 2 years ago

Describe the bug

Hello 👋
Since I switched from "18.0.2" to "19.0.1", Typescript does not compile anymore

Version

19.0.1

Expected behavior

Typescript should compile without any error message.

Actual behavior

I have the following error:

Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/anthonny/projects/aaa/node_modules/@keycloak/keycloak-admin-client/lib/index.js from /Users/anthonny/projects/aaa/packages/api/infra/server/keycloak-plugin.ts not supported.
Instead change the require of index.js in /Users/anthonny/projects/aaa/packages/api/infra/server/keycloak-plugin.ts to a dynamic import() which is available in all CommonJS modules.

How to Reproduce?

I have a Typescript project with this tsconfig.json:

{
  "extends": "@tsconfig/node16/tsconfig.json",
  "compilerOptions": {
    "outDir": "dist"
  }
}

Just import the lib and use the client

Anything else?

Everything is ok if I go back to "18.0.2", thank you for your support 🙏😘

Mariusz Beltowski commented 2 years ago

Same here

Manuel Henke commented a year ago

:(

Lucas Araujo · Answer 1 · Wed Aug 10 2022 03:06:56 GMT+0800 (China Standard Time)

I was about to open an issue too. Coincidentally we're facing the exact same issue on a Node project... Downgrading to v18.0.2 worked too.

Jon Koops · Answer 2 · Sat Aug 13 2022 18:55:09 GMT+0800 (China Standard Time)

Just set a new project with TypeScript and this compiles fine with the given information in this bug report (see keycloak-admin-ts.zip). Please provide a complete reproducible example with as little code as possible.

abretonc7s · Answer 3 · Mon Aug 15 2022 21:32:13 GMT+0800 (China Standard Time)

+1 Same error

Philipp Bucher · Answer 4 · Tue Aug 16 2022 17:00:15 GMT+0800 (China Standard Time)

+1 18.0.2 is broken

@jonkoops

Import is done like this in my project (nestjs)

import KcAdminClient from '@keycloak/keycloak-admin-client';

This Problem was introduced via 4a7c1e0

Jon Koops · Answer 5 · Tue Aug 16 2022 17:47:47 GMT+0800 (China Standard Time)

@GerDner I just booststrapped a new NestJS project and this works fine for me using the latest version of the Admin Client.

Philipp Bucher · Answer 6 · Tue Aug 16 2022 20:43:21 GMT+0800 (China Standard Time)

@jonkoops i reproduced it with a new nestjs project via npx create-nx-workspace@latest keycloak (nx workspaces) but not with nest new.
I did not find any difference in ts-config params which could cause such an error.

Jon Koops · Answer 7 · Tue Aug 16 2022 20:46:09 GMT+0800 (China Standard Time)

@GerDner could it be that some compiler bits are different? Such as the TypeScript version?

Jon Koops · Answer 8 · Tue Aug 16 2022 21:04:53 GMT+0800 (China Standard Time)

Looks like the authors of NestJS have expressed that they have no interest in implementing support for loading pure ES modules (see nestjs/nest#7021 (comment)). This was over a year ago so perhaps this opinion has changed.

Either way this is an issue with NestJS, so I'd recommend you log an issue there. The more people ask for it the more likely it will be implemented.

Yagiz Nizipli · Answer 9 · Sat Aug 20 2022 23:24:37 GMT+0800 (China Standard Time)

The amount of pain the decision to convert the codebase is huge. Especially on packages that depend on this package.

There isn't any logical reasoning behind converting a package to ESM only in terms of performance. Actually using ESM has worse performance than CJS in Node.js. (nodejs/node#44186)

I recommend the distributors of this package change their decision and ease the pain of using this package.

The community is not ready for this kind of change.

Lucas Araujo · Answer 10 · Sun Aug 21 2022 09:24:33 GMT+0800 (China Standard Time)

I recommend the distributors of this package change their decision and ease the pain of using this package.
The community is not ready for this kind of change.

Totally agree.

Jon Koops · Answer 11 · Tue Aug 23 2022 04:42:16 GMT+0800 (China Standard Time)

We're not going backwards in time and refit a module system that was never formally accepted into the language. Instead we will focus on implementing something that is actually standardized and is the future of the language as a whole, not just the Node.js ecosystem.

I recommend the distributors of this package change their decision and ease the pain of using this package.
The community is not ready for this kind of change.

ES modules are marked as stable in Node.js 14, 16 and 18. All modern tooling such as esbuild, Vite, SWC, WebPack, Rollup, etc. are all optimized around ES modules. So this seems a very alarmist statement to me.

In the end we need to move towards a common target so we can get out of this mess, that will (and already is in most cases) ECMAScript, not CommonJS.

As far as nodejs/node#44186 goes, the very assertion here is refuted by the last comment in the thread. And even if it wasn't then it is simply something that needs to be fixed in Node.js.

Mike Drakoulelis · Answer 12 · Tue Aug 23 2022 16:32:24 GMT+0800 (China Standard Time)

I applaud the move forward, yet this is a breaking change not mentioned anywhere clearly, and blocks development with mayor frameworks such as NestJS.

@GerDner I just booststrapped a new NestJS project and this works fine for me using the latest version of the Admin Client.

Could you upload it to a demo repo? I have done the same using the latest NestJS CLI and cannot create the Admin Client without triggering the error.

Jon Koops · Answer 13 · Sun Sep 04 2022 04:49:40 GMT+0800 (China Standard Time)

Yeah, apologies for the lack of communication on our part. I am working on de-coupling this library from the release cycle of the main Keycloak project (currently this is tied into the same scripts). This way we can independently version the project and add proper release notes.

I think I made a mistake in my original NestJS project, bootstrapping one now seems to cause the same issue as mentioned before.

Mica Hallin · Answer 14 · Tue Sep 06 2022 18:04:32 GMT+0800 (China Standard Time)

I used this workaround in NestJS:

//global helper method :
const dynamicImport = async (packageName: string) =>
  new Function(`return import('${packageName}')`)();

// trick to keep dependencies into my webpack build
const nottrue = false;
if (nottrue) import('@keycloak/keycloak-admin-client');

// Dynamic import of ESM lib
const KCadmCli = (
  await dynamicImport('@keycloak/keycloak-admin-client')
).default;

Dallas Phillips · Answer 15 · Wed Oct 05 2022 06:07:05 GMT+0800 (China Standard Time)

This opinioned enforcement effectively breaks typescript + node + cjs which is not in a long shot a minority group of developers. This type of enforcement with no communication or migration path for a large group of devs is just lazy.

Philipp Bucher · Answer 16 · Thu Oct 06 2022 19:14:19 GMT+0800 (China Standard Time)

I used this workaround in NestJS:

//global helper method :
const dynamicImport = async (packageName: string) =>
  new Function(`return import('${packageName}')`)();

// trick to keep dependencies into my webpack build
const nottrue = false;
if (nottrue) import('@keycloak/keycloak-admin-client');

// Dynamic import of ESM lib
const KCadmCli = (
  await dynamicImport('@keycloak/keycloak-admin-client')
).default;

i can confirm that this works

Dallas Phillips · Answer 17 · Thu Oct 06 2022 22:53:13 GMT+0800 (China Standard Time)

A workaround for Typescript would also be nice if it is even possible, so far I have not found any examples anywhere of dynamically importing a type.

Manuel Baun · Answer 18 · Mon Oct 10 2022 20:20:45 GMT+0800 (China Standard Time)

I also got this issue, where I try to import the package and it throws ERR_REQUIRE_ESM evetything I have tried, does not work to make this package work with my server application (use commonjs).

I use a workaround, where I setup an npm package and use esbuild to bundle keycloak-nodejs-admin-client and then export the js file with its index.d.ts file. This is my package.json

{
    "name": "@packages/keycloak-cjs",
    "version": "1.0.0",
    "main": "./index.js",
    "types": "./index.d.ts",
    "scripts": {
        "build": "esbuild index.ts --platform=node --bundle --format=cjs --outfile=index.js"
    },
    "dependencies": {
        "@keycloak/keycloak-admin-client": "^19.0.3"
    }
}

my index.ts and index.d.ts files

import Keycloak from '@keycloak/keycloak-admin-client';

export {Keycloak };

then I install my package and use it in my source code. I use pnpm workspaces

Yuval Ron · Answer 19 · Wed Nov 09 2022 12:39:52 GMT+0800 (China Standard Time)

Too bad that this issue is closed without a solution. The hassle of a workaround in my case would opt me out to search for alternatives or write my own client.

Dallas Phillips · Answer 20 · Wed Nov 09 2022 13:25:23 GMT+0800 (China Standard Time)

@JAZZ-FROM-HELL that's what we ended up doing as well. Too bad they didn't consider the ramifications of them enforcing ESM like this with no notice. Bad opensource.

Manuel Baun · Answer 21 · Wed Nov 16 2022 02:35:07 GMT+0800 (China Standard Time)

@DallasP9124 is you code opensource as well?

Dallas Phillips · Answer 22 · Wed Nov 16 2022 02:42:03 GMT+0800 (China Standard Time)

@Manuelbaun Im not providing a library for others to use, where this project is. That's the main difference.

yossir-dp · Answer 23 · Sun Dec 11 2022 20:34:51 GMT+0800 (China Standard Time)

I also got this issue, where I try to import the package and it throws ERR_REQUIRE_ESM evetything I have tried, does not work to make this package work with my server application (use commonjs).

I use a workaround, where I setup an npm package and use esbuild to bundle keycloak-nodejs-admin-client and then export the js file with its index.d.ts file. This is my package.json
{
    "name": "@packages/keycloak-cjs",
    "version": "1.0.0",
    "main": "./index.js",
    "types": "./index.d.ts",
    "scripts": {
        "build": "esbuild index.ts --platform=node --bundle --format=cjs --outfile=index.js"
    },
    "dependencies": {
        "@keycloak/keycloak-admin-client": "^19.0.3"
    }
}
my index.ts and index.d.ts files
import Keycloak from '@keycloak/keycloak-admin-client';

export {Keycloak };
then I install my package and use it in my source code. I use pnpm workspaces

Hi @Manuelbaun, could you perhaps elaborate more on your solution?
Does he provide you with TS support? Also in watch mode before build?
Thank you

Manuel Baun · Answer 24 · Mon Dec 12 2022 19:33:02 GMT+0800 (China Standard Time)

Hi @yossir-dp,

esbuild takes the keycload classes and bundles them into one single index.js file. For the types, I just created the index.d.ts file and it looks exactly as my index.ts file. So when I import this libaries into my code, I get all types, because the path to the types are specified in the package.json under the types-key. I hope this helps..

Duc Trung Mai · Answer 25 · Sat Dec 17 2022 18:15:01 GMT+0800 (China Standard Time)

have to downgrade to 18.0.2, just because of this

Murat Karagözgil · Answer 26 · Mon Jan 02 2023 17:50:44 GMT+0800 (China Standard Time)

Yes 18.0.2 version is good, but what a bad problem, Will we be able to upgrade again?

Dallas Phillips · Answer 27 · Mon Jan 02 2023 23:07:25 GMT+0800 (China Standard Time)

@MuratKaragozgil not unless you fork this and undo all the esm stuff, or, you can write your own admin client, which is what we did. Wasn't too much effort really. And their API is stable so it isn't likely to change much if at all.

glappsi · Answer 28 · Thu Feb 23 2023 21:55:05 GMT+0800 (China Standard Time)

We're not going backwards in time and refit a module system that was never formally accepted into the language. Instead we will focus on implementing something that is actually standardized and is the future of the language as a whole, not just the Node.js ecosystem.

I recommend the distributors of this package change their decision and ease the pain of using this package.
The community is not ready for this kind of change.

ES modules are marked as stable in Node.js 14, 16 and 18. All modern tooling such as esbuild, Vite, SWC, WebPack, Rollup, etc. are all optimized around ES modules. So this seems a very alarmist statement to me.

In the end we need to move towards a common target so we can get out of this mess, that will (and already is in most cases) ECMAScript, not CommonJS.

As far as nodejs/node#44186 goes, the very assertion here is refuted by the last comment in the thread. And even if it wasn't then it is simply something that needs to be fixed in Node.js.

I find this kind of a narrow minded answer. Of course ESM should be the future, and it's important for every library to support it. But to limit it to this is bullshit. I, as an example, am not able to convert my project to ESM because it relies on sequlize-typescript which is not compatible with ESM. Using a different ORM is complete out of proportion. So what possibilities do I have now, since my project is also required to use keycloak? I wanted to upgrade to v21, but now I am forced to use v18 just because this library does not support commonjs?! I am not sure if you guys do the community a favor with that.

glappsi · Answer 29 · Fri Feb 24 2023 18:35:12 GMT+0800 (China Standard Time)

@jonkoops I have created a working branch with both, esm and cjs, in it locally. If you give me rights to push a new branch a could push the changes and create a PR?

kschroeder-of · Answer 30 · Tue Mar 07 2023 19:48:06 GMT+0800 (China Standard Time)

@jonkoops I have created a working branch with both, esm and cjs, in it locally. If you give me rights to push a new branch a could push the changes and create a PR?

Can we create a pull request for that in the Keycloak repository, as this lib was moved there?

Or is there any other news on the topic?