Error [ERR_REQUIRE_ESM]

[anthonny]

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 🙏😘

[KiriLucas]

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.

[jonkoops]

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]

+1 Same error

[GerDner]

+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 4a7c1e06880e2f6b44fe6c04acf6f18224663cfa

[jonkoops]

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

[GerDner]

@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.

[jonkoops]

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

[jonkoops]

Looks like the authors of NestJS have expressed that they have no interest in implementing support for loading pure ES modules (see https://github.com/nestjs/nest/issues/7021#issuecomment-831799620). 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.

[anonrig]

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. (https://github.com/nodejs/node/issues/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.

[KiriLucas]

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.

[jonkoops]

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 https://github.com/nodejs/node/issues/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.

[Nosfistis]

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.

[jonkoops]

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.

[hmica]

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;

[BigBallard]

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.

[GerDner]

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

[BigBallard]

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.

[Manuelbaun]

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

[JAZZ-FROM-HELL]

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.

[BigBallard]

@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.

[Manuelbaun]

@DallasP9124 is you code opensource as well?

[BigBallard]

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

[mariuszbeltowski]

Same here

[yossir-dp]

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

[Manuelbaun]

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..

[maitrungduc1410]

have to downgrade to 18.0.2, just because of this

[MuratKaragozgil]

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

[BigBallard]

@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.

[mhenke96]

:(

[glappsi]

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.