Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

293
Views
proporcionar campos de módulo, principal y navegador que satisfagan esm, commonjs y bundlers

Tengo varios paquetes npm publicados que he actualizado para proporcionar compilaciones commonjs y esm. Algunos de los paquetes pueden ser tanto para el nodo como para el navegador. Todos los paquetes compilados con webpack o rollup. Todos están escritos a máquina y transpilados a un directorio dist .

Creo un archivo commonjs index.js que se parece a esto:

 'use strict' if (process.env.NODE_ENV === 'production') { module.exports = require('./react-abortable-fetch.cjs.production.min.js') } else { module.exports = require('./react-abortable-fetch.cjs.development.js') }

Establecí el campo main de package.json en el archivo index.js anterior.

También genero un archivo .esm.js para cada paquete y configuro los campos del browser y del module en el archivo esm.js y configuro el type de archivo para que sea module .

El resultado final es algo como esto:

 "type": "module", "main": "dist/index.js", "browser": "dist/react-abortable-fetch.esm.js", "module": "dist/react-abortable-fetch.esm.js", "types": "dist/index.d.ts",

El problema con este enfoque es que solo los paquetes esm pueden consumirlo (a menos que me equivoque).

¿Cuál es la mejor manera de configurar el archivo package.json para que los paquetes que aún no han dado el salto (y son bastantes) aún puedan consumir el paquete?

over 4 years ago · Santiago Trujillo
1 answers
Answer question

0

La idea es aprovechar las exportaciones condicionales de Node.js para personalizar el comportamiento de importación según cómo importe el módulo ( require o import ).

Para tener dos interfaces diferentes para CommonJS y ESM, puede:

  • Transpilar tanto a CommonJS como a ESM (permite usar accidentalmente import y require para su biblioteca en la misma aplicación, lo que podría causar comportamientos no deseados e impredecibles)
  • Tenga la implementación como ESM y un contenedor CommonJS (no es posible porque no puede require un módulo ECMAScript cuando tiene await de nivel superior)
  • Tener la implementación como CommonJS y un contenedor ESM (la mejor solución real)

Por lo tanto, debe configurar CommonJS como un destino de transpilación de TypeScript y luego crear un contenedor ESM (preferiblemente en una carpeta dedicada). Finalmente, asigne los puntos de entrada CommonJS y ESM a los archivos correspondientes en el package.json :

 "exports": { "require": "./index.js", "import": "./esm/index.js" }

He publicado un proyecto de trabajo mínimo aquí: https://github.com/Guerric-P/demo-commonjs-esm

Para usar las bibliotecas en TypeScript, también necesita un archivo .d.ts aparte de cada archivo JavaScript.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!