Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Any option for ESM support in current release?

Aperta
  • Qualcosa non va?
#3,397 1 commento 3 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
node.js, typescript
Ambito
api

Direzione di ricerca

Inizia riproducendo il comportamento segnalato con il progetto di esempio allegato, in particolare base.mts, classic.ts, commonjs.cts, esm.mts e implicit.ts, utilizzando le impostazioni di package.json e tsconfig.json descritte. Leggi le issues #3335 e #3337 insieme alla riproduzione; il lavoro è completo quando i progetti ESM attuali hanno un modo documentato e verificato per usare @googleapis/sheets, oppure quando il supporto richiesto è chiaramente definito.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

priority: p3 type: question

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.

Lingua principale
TypeScript
Stelle
12.3k
Fork
2k
Merge medio
1g 19h
PR unite (30g)
21

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di googleapis/google-api-nodejs-client

Tutte le issue di googleapis/google-api-nodejs-client

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.