updating package version results in ES Module errors when using NestJs

[dbrcplex]

I have been using "@kubernetes/client-node": "^0.18.1" in my package.json and it works.

If I update the version to 1.0.0 - "@kubernetes/client-node": "^1.0.0" I get errors:

"require() of ES Module /home/app/kubernetes-test/node_modules/@kubernetes/client-node/dist/index.js from /home/app/kubernetes-test/dist/app.service.js not supported.\nInstead change the require of index.js in /home/app/kubernetes-test/dist/app.service.js to a dynamic import() which is available in all CommonJS modules."

This is my import statement when using v 0.18.1

import * as k8s from '@kubernetes/client-node';

Based on the ES Module error I have removed that import and have tried this but it does not work:

const k8s = require('@kubernetes/client-node'); const kc = new k8s.KubeConfig(); kc.loadFromFile(KUBECONFIGSPATH + '/' + body.kubeconfig);

I have also tried a dynamic import and that also results in the same ES Module error.

await import('@kubernetes/client-node') .then((k8s)=>{
const kc = new k8s.KubeConfig(); kc.loadFromFile(KUBECONFIGSPATH + '/' + body.kubeconfig);
const apiclient = kc.makeApiClient(k8s.CoreV1Api);

Based on what I have been reading it sounds like my package.json and/or tsconfig.json may also need to be updated but whatever combination(s) I have tried have also not worked.

Does anyone have a working example of using v1.0.0 and NestJS?

[brendandburns]

Have a look at this issue which is not NestJS but is similar:

https://github.com/kubernetes-client/javascript/issues/2142

1.0.0 switched to ESM modules, you probably need to update the module spec in your tsconfig.

[rossanthony]

I ran into similar issues, in a typescript project that uses Jest, but was able to work around it by adding these two packages as dev dependencies:

"@babel/preset-env"
"@babel/preset-typescript"

Then added this to jest.config.js

    transformIgnorePatterns: ['/node_modules/(?!(@kubernetes/client-node|openid-client|oauth4webapi))'],
    transform: {
        "^.+\\.[tj]s$": "babel-jest",
    },

Also had to add a babel.config.js:

module.exports = {
    presets: [
        '@babel/preset-env',
        '@babel/preset-typescript'
    ],
};

This then ensures that when running tests written in typescript using Jest, it will compile the ES modules of the dependencies into CommonJS so they can be imported. The ES modules exported by @kubernetes/client-node are basicallly transformed by Babel, allowing Jest to handle the ES module syntax correctly.

[JanPfenning]

@rossanthony is there any way to archive similar without the use of babel? We use other things like experimental annotations that make the use of babel for our project currently not suited.

[rossanthony]

Good question @JanPfenning - I'm not sure of another way to make this work in a Typescript project that is setup to compile to CommonJS. There's a possibility that the kube client library itself could be modified so it compiles two versions so it can support both ESM + CommonJS, I've not tried this myself but it sounds like it could be possible based on the approach outlined in this article: https://www.embedthis.com/blog/sensedeep/how-to-create-single-source-npm-module.html

[lucavb]

Is there interest from the project maintainers in offering a CommonJS version alongside the ESM version? We are facing challenges upgrading to version 1.0.0 at my client because our tests are still run using Jest. Although I managed to configure Jest to work, the transpilation of the client is extremely slow. Migrating to Vitest is unfortunately not as straightforward as I hoped, so we are sticking with Jest for now. I experimented with the approach mentioned in the article shared by @rossanthony, which does work, but it disrupted some other configurations. If there is interest in providing a CommonJS version, I would be willing to raise a PR.

[lucavb]

I took the liberty of assuming that is will not receive a hard no and raised this PR -> https://github.com/kubernetes-client/javascript/pull/2240

[charankumarpalla]

@dbrcplex

Just in case this helps…

Try updating your Node.js version—specifically to 22.14. Based on this comment, I updated my Node.js version, and it worked.

const client_node_1 = require("@kubernetes/client-node");
                      ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /opt/charan/src/node_modules/@kubernetes/client-node/dist/index.js from /opt/charan/src/build/demo/sample.js not supported.
Instead change the require of index.js in /opt/charan/src/build/demo/sample.js to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/opt/app-root/src/build/controller/cronJob.js:5:23) {
  code: 'ERR_REQUIRE_ESM'
}

[JanPfenning]

we chanced our test script to use --experimental-vm-modules which resolved issues in jest

"test": "node --experimental-vm-modules node_modules/jest/bin/jest.js --coverage --silent"

[cjihrig]

Just FYI for folks - I came across this discussion today regarding ESM and Jest - https://github.com/panva/jose/discussions/766. This is one of our nested dependencies that forced our move to ESM in v1. Maybe this can help some folks out.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.