Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

300
Vistas
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 Respuestas
Responde la pregunta

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 Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda