Error [ERR_REQUIRE_ESM] about keycloak-nodejs-admin-client HOT 32 CLOSED

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.

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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;

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

:(

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

+1 Same error

from keycloak-nodejs-admin-client.

+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

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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.

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

@DallasP9124 is you code opensource as well?

from keycloak-nodejs-admin-client.

Same here

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

have to downgrade to 18.0.2, just because of this

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.

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

from keycloak-nodejs-admin-client.