Status de suporte atual para módulos ECMAScript (ESMs) no Node.js:
- O suporte experimental ao ESM foi adicionado ao Node.js 8.5.0 em 12 de setembro de 2017.
- Depois disso, o Comitê Técnico de Direção do Node.js. formou a equipe responsável pela equipe de módulos para ajudar a projetar as peças ausentes para a próxima versão (não experimental). Essa equipe é formada por pessoas de vários setores de desenvolvimento da Web (front-end, back-end, mecanismos JS, etc.).
Em outubro, a equipe de módulos publicou o "Plano de implementação de novos módulos" . Esta postagem explica o que ela contém.
Fases
O processo é dividido em três fases:
- Fase 1: crie um núcleo "mínimo" - o conjunto básico de regras e recursos, o mínimo e o mais seguro possível.
- Fase 2 em diante: criando funcionalidades mais complexas baseadas no kernel.
Um núcleo mínimo será a base para trabalhos futuros. O novo design também substituirá a implementação experimental atual assim que adquirir recursos semelhantes.
Fase 1: suporte básico mínimo ao ESM no Node.js
Simplificação de identificadores de módulo
Um dos objetivos da equipe de módulos é alcançar a “equivalência do navegador” : o Node.js deve estar o mais próximo possível dos navegadores. O kernel consegue isso simplificando a análise de identificadores de módulo (URLs apontando para módulos):
- Cada identificador de módulo deve terminar com um nome de arquivo com a extensão. Isso é
- Extensões não são adicionadas automaticamente
- A importação de diretórios não é suportada (por meio do redirecionamento para
dir/index.mjs ou pela leitura do campo main em package.json ).
- Os módulos ES podem importar módulos internos do Node.js. (
path e similares). Eles são a única exceção à regra anterior. - Por padrão, apenas os arquivos com a extensão
.mjs são .mjs (consulte a Fase 2 se você estiver interessado no status de outras extensões). Portanto, outros tipos de módulos não podem ser importados através da import : módulos CommonJS, arquivos JSON, módulos nativos.
Trazendo recursos essenciais do CommonJS aos módulos ES
- URL do módulo atual (semelhante ao
__filename do CommonJS): import.meta.url - Importe dinamicamente os módulos ES (disponíveis por meio de
require() no CommonJS): import()
Compatibilidade
- Os módulos ES poderão importar módulos CommonJS por meio de
createRequireFromPath() . Isso funcionará da seguinte maneira (há planos para criar um método abreviado, por exemplo, a função 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');
- Os módulos CommonJS poderão carregar os módulos ES através de
import() .
Fase 2 e planos futuros
- Na segunda fase, estamos aguardando:
- Suporte para identificadores "simples", como
'lodash' . Provavelmente, isso incluirá alguma maneira de mapear esses identificadores para caminhos reais. - Suporte para outras extensões de arquivo além do
.mjs . Isso inclui, entre outras coisas, suporte para módulos ES em arquivos .js .
- A fase 3 provavelmente se concentrará nos carregadores de módulos com pontos de extensão em que os usuários podem conectar sua lógica.
Quando posso usar os módulos ES no Node.js?
- Atrás da bandeira: disponível agora
- Cuidado: o comportamento ainda não corresponde ao descrito acima na fase 1 (a partir do Node.js. 11.5.0)
- Sem uma bandeira e de acordo com a fase 1: a equipe de módulos está tentando tornar isso possível o mais rápido possível. Esperamos que os módulos sejam liberados do sinalizador no Node.js. 14 (abril de 2020) e portados para versões anteriores, se possível.
Perguntas frequentes
- Por que preciso de uma nova
.mjs arquivo .mjs ?
- Cada decisão de distinguir entre os formatos ESM e CommonJS tem suas vantagens e desvantagens. Usar uma resolução separada parece ser uma boa opção ( mais informações ).
- Por que o Node.js deve se comportar como um navegador?
- Porque isso possibilita a reutilização de código. Por exemplo, para criar bibliotecas que funcionam nos navegadores e no Node.js
- Isso também deve facilitar a alternância entre o back-end e o front-end durante a codificação.
- Por que todas essas restrições para compatibilidade?
- Existem diferenças bastante fortes entre os módulos ES e CommonJS na estrutura (estática versus dinâmica) e no método de carregamento (assíncrono versus síncrono). As restrições ajudam a simplificar as coisas - já que, a longo prazo, a grande maioria será de módulos ES.
- Por que tudo isso dura tanto tempo?
- Muitas partes interessadas estão envolvidas aqui e muitas plataformas diferentes (Node.js, npm, navegadores, mecanismos JS, TypeScript, TC39 e outros). Se realmente adquirirmos módulos ES que podem funcionar em qualquer lugar, provavelmente vale a pena esperar, IMHO.
Gratidão
Obrigado a Miles Borins por seus comentários sobre este post.
Recursos adicionais para leitura adicional