Skip to content
This repository has been archived by the owner on Apr 19, 2023. It is now read-only.

Error [ERR_REQUIRE_ESM] #523

Closed
anthonny opened this issue Aug 8, 2022 · 32 comments
Closed

Error [ERR_REQUIRE_ESM] #523

anthonny opened this issue Aug 8, 2022 · 32 comments

Comments

@anthonny
Copy link

anthonny commented Aug 8, 2022

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
Copy link

KiriLucas commented Aug 9, 2022

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
Copy link
Contributor

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
Copy link

+1 Same error

@GerDner
Copy link

GerDner commented Aug 16, 2022

+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

@jonkoops
Copy link
Contributor

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

@GerDner
Copy link

GerDner commented Aug 16, 2022

@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
Copy link
Contributor

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

@jonkoops
Copy link
Contributor

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.

@jonkoops jonkoops closed this as not planned Won't fix, can't repro, duplicate, stale Aug 16, 2022
@anonrig
Copy link

anonrig commented Aug 20, 2022

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.

@KiriLucas
Copy link

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
Copy link
Contributor

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.

@Nosfistis
Copy link

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
Copy link
Contributor

jonkoops commented Sep 3, 2022

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
Copy link

hmica commented Sep 6, 2022

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
Copy link

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
Copy link

GerDner commented Oct 6, 2022

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
Copy link

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
Copy link

Manuelbaun commented Oct 10, 2022

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
Copy link

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
Copy link

@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
Copy link

@DallasP9124 is you code opensource as well?

@BigBallard
Copy link

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

@mariuszbeltowski
Copy link

Same here

@yossir-dp
Copy link

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
Copy link

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
Copy link

maitrungduc1410 commented Dec 17, 2022

have to downgrade to 18.0.2, just because of this

@MuratKaragozgil
Copy link

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

@BigBallard
Copy link

@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
Copy link

:(

@glappsi
Copy link

glappsi commented Feb 23, 2023

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
Copy link

glappsi commented Feb 24, 2023

@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
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests