Estado actual de soporte para módulos ECMAScript (ESM) en Node.js:
- El soporte experimental de ESM se agregó en Node.js 8.5.0 el 12 de septiembre de 2017.
- Después de eso, el Comité de Dirección Técnica de Node.js formó el equipo responsable del Equipo de Módulos para ayudar a diseñar las partes faltantes para el próximo lanzamiento (no experimental). Este equipo está formado por personas de diversas industrias de desarrollo web (frontend, back-end, motores JS, etc.).
En octubre, el Equipo de Módulos publicó el "Plan de Implementación de Nuevos Módulos" . Esta publicación explica lo que contiene.
Fases
El proceso se divide en tres fases:
- Fase 1: cree un núcleo "mínimo": el conjunto básico de reglas y capacidades, lo más mínimo y seguro posible.
- Fase 2 en adelante: crear una funcionalidad más compleja basada en el núcleo.
Un núcleo mínimo será la base para el trabajo futuro. El nuevo diseño también reemplazará la implementación experimental actual tan pronto como adquiera capacidades similares.
Fase 1: soporte mínimo de ESM central en Node.js
Simplificación de los identificadores del módulo.
Uno de los objetivos del equipo de módulos es lograr la "equivalencia del navegador" : Node.js debe estar lo más cerca posible de los navegadores. El núcleo logra esto al simplificar el análisis de los identificadores de módulo (URL que apuntan a módulos):
- Cada identificador de módulo debe terminar con un nombre de archivo con la extensión. Eso es
- Las extensiones no se agregan automáticamente
- No se admite la importación de directorios (ya sea a través de la redirección a
dir/index.mjs o leyendo el campo main en package.json ).
- Los módulos ES pueden importar módulos Node.js integrados (
path y similares). Son la única excepción a la regla anterior. - De manera predeterminada, solo se
.mjs archivos con la extensión .mjs (consulte la Fase 2 si está interesado en el estado de otras extensiones). Por lo tanto, no se pueden importar otros tipos de módulos a través de la import : módulos CommonJS, archivos JSON, módulos nativos.
Trayendo características esenciales de CommonJS a los módulos ES
- URL del módulo actual (similar a
__filename de CommonJS): import.meta.url - Importe dinámicamente módulos ES (disponibles a través de
require() en CommonJS): import()
Compatibilidad
- Los módulos ES podrán importar módulos
createRequireFromPath() través de createRequireFromPath() . Esto funcionará de la siguiente manera (hay planes para crear un método abreviado, por ejemplo, la función createRequireFromUrl() ):
import {createRequireFromPath as createRequire} from 'module'; import {fileURLToPath as fromPath} from 'url'; const require = createRequire(fromPath(import.meta.url)); const cjsModule = require('./cjs-module.js');
- Los módulos CommonJS podrán cargar módulos ES a través de
import() .
Fase 2 y planes futuros
- En la segunda fase, estamos esperando:
- Soporte para identificadores "desnudos" como
'lodash' . Lo más probable es que esto incluya alguna forma de mapear estos identificadores a rutas reales. - Soporte para otras extensiones de archivo además de
.mjs . Esto incluye, entre otras cosas, soporte para módulos ES en archivos .js .
- La Fase 3 probablemente se centrará en los cargadores de módulos con puntos de extensión donde los usuarios pueden conectar su lógica.
¿Cuándo puedo usar módulos ES en Node.js?
- Detrás de la bandera: disponible ahora
- Advertencia: el comportamiento aún no coincide con el descrito anteriormente en la fase 1 (a partir de Node.js 11.5.0)
- Sin una bandera y de acuerdo con la fase 1: el equipo de módulos está tratando de hacer esto posible lo antes posible. Esperamos que los módulos sean lanzados bajo la bandera en Node.js 14 (abril de 2020) y portados a versiones anteriores, si es posible.
Preguntas frecuentes
- ¿Por qué necesito una nueva
.mjs archivo .mjs ?
- Cada decisión de distinguir entre los formatos ESM y CommonJS tiene sus ventajas y desventajas. Usar una resolución separada parece una buena opción ( más información ).
- ¿Por qué Node.js debería comportarse como un navegador?
- Porque hace posible reutilizar el código. Por ejemplo, para crear bibliotecas que funcionen tanto en navegadores como en Node.js
- Esto también debería facilitar el cambio entre el backend y el frontend durante la codificación.
- ¿Por qué todas estas restricciones de compatibilidad?
- Existen diferencias bastante fuertes entre los módulos ES y CommonJS en la estructura (estática versus dinámica) y la forma de carga (asincrónica versus síncrona). Las restricciones ayudan a simplificar las cosas, dado que a la larga, la gran mayoría serán módulos ES.
- ¿Por qué todo dura tanto?
- Aquí participan muchas partes interesadas y muchas plataformas diferentes (Node.js, npm, navegadores, motores JS, TypeScript, TC39 y otros). Si realmente obtenemos módulos ES que pueden funcionar en todas partes, probablemente valga la pena la espera, en mi humilde opinión.
Gratitud
Gracias a Miles Borins por sus comentarios sobre esta publicación.
Recursos adicionales para lecturas adicionales