Any option for ESM support in current release?

[nlwillia]

I'm attempting to port a node TypeScript project to use the ESM support in newer versions of node and TypeScript.

TypeScript has muddied the water historically by supporting ESM style import/export syntax but still emitting CommonJS format modules for the node ecosystem. Moving things forward means increased consciousness of output format, understanding the format of libraries and falling back to dynamic imports when needed to pull in things that are only still available as CommonJS.

The only dependency that I'm running into a wall with for this project is @googleapis/sheets. It's written in TypeScript, but published as CommonJS with types bundled. That worked when my code was also CommonJS under the hood, but I can't figure out an equivalent way to reference what I need from it in ESM TypeScript.

Attached is an example project showing various approaches. Note the "type": "module" in package.json and the "module": "NodeNext" in tsconfig.json. The intent is to write TypeScript in ESM format, emit verbatim ESM and pull in CommonJS where necessary via import().

• base.mts - A base class to force other modules to integrate with something in explicitly ESM format.
• classic.ts - How we would have used the sheets API historically. But this fails when we try to pull in base because using sheets forces us to CommonJS under the hood so we can't use pure ESM directly. TS1479: The current file is a CommonJS module whose imports will produce  require  calls; however, the referenced file is an ECMAScript module and cannot be imported with  require . Consider writing a dynamic  import(  ./base.mjs )' call instead.
• commonjs.cts - The same scenario/problem as classic, just using CommonJS explicitly instead of TypeScript's sugared import/export syntax.
• esm.mts - An explicitly ESM module. This compiles because it's only dependent on sheets at the type level, and that all gets stripped out in the build. I'm not sure if it would work with more substantial integration since it would be producing ESM style imports for a CommonJS module which wouldn't resolve at runtime.
• implicit.ts - An implicitly ESM module because the package is ESM and because of the tsconfig. It's trying to use dynamic import but runs into problems because things like interfaces aren't part of the build structure and the classes can only be referenced with typeof.

I see #3335 and #3337 to improve ESM support, but I'm interested in any workaround I'm overlooking with the current version that would make this usable in an ESM project. At this point sandboxing it as .cts and converting all the ESM imports it needs to dynamic imports seems most equivalent, but it's non-trivial because all of those then have to be dealt with as async.

[sofisl]

Hi @nlwillia, we don't have plans on making this library ESM. However, as a workaround, you could try esm.sh for now. I haven't played too much with attempting to use this library in ESM, so I'll have to keep this issue open and think about it some more.