Fix for client-node ESM v Commonjs issue.

[Tatsinnit]

This PR is open with intent to fix #130

This PR addresses and fixes the issue where the Kubernetes client (@kubernetes/client-node) had compatibility problems with ESM (ECMAScript Modules) and CommonJS. This PR fix resolves the syntax errors related to the use of export in CommonJS contexts and ensures smoother integration.

Additionally, it includes the necessary adjustments to configuration and module handling, improving the overall compatibility with newer module systems.

Thanks heaps, ❤️

[bosesuneha]

Thanks for the PR, @Tatsinnit! It looks great! Could you add some notes in the description for future reference in case we need to revisit this PR for a similar issue?

[Tatsinnit]

Thanks for the PR, @Tatsinnit! It looks great! Could you add some notes in the description for future reference in case we need to revisit this PR for a similar issue?

Thank you @bosesuneha , essentially there is no silver bullet for these fixes but I am about to gist the key thing and starting point how we will handle.

Information built-up:

• Client-node has decided to only support ESM which mean the commons projects will see ESM errors.
• Best place to see if our project is ESM or not is package.json - type: "module" - will mean it its ESM support, so in this project this was my starting point, then the mix will come, after checking all was using import next was track down errors and handle one error at a time.

For this specific case adding babel did the magic and then this: https://jestjs.io/docs/ecmascript-modules came handy.

ESM vs Commonjs

ESM:

ESM also known as (ECMAScript Modules):

• Static Structure: Imports and exports are static. This means they are determined at compile time, which allows for better static analysis and tree-shaking (removing unused code during bundling).
• Standardized: ESM is part of the official ECMAScript standard and is now natively supported by modern browsers and Node.js (with some configuration).
• Asynchronous Loading: ESM supports asynchronous module loading, which can be beneficial for performance in certain scenarios (especially in browser environments).

CommonJS

• Dynamic Structure: CommonJS modules are loaded at runtime, which allows for dynamic imports (e.g., conditional or computed module paths). However, this dynamism makes static analysis and tree-shaking more challenging.
• Traditional in Node.js: CommonJS has been the de facto module system for Node.js for many years, and many packages in the Node ecosystem still use it.

I am sure there is more but hope this gives some insight as to how I thought this could be solved until it was all good and green.

Thanks.

[ReinierCC]

Great solution! and thanks for the explaination!