El uso de Node.js requiere vs. ES6 importación / exportación

En un proyecto en el que estoy colaborando, tenemos dos opciones sobre qué sistema de módulos podemos usar:

1. Importando módulos usando require, y exportando usando module.exportsy exports.foo.
2. Importar módulos con ES6 importy exportar con ES6export

¿Hay algún beneficio de rendimiento al usar uno sobre el otro? ¿Hay algo más que deberíamos saber si tuviéramos que usar módulos ES6 sobre nodos?

¿Hay algún beneficio de rendimiento al usar uno sobre el otro?

Tenga en cuenta que todavía no hay un motor de JavaScript que admita de forma nativa los módulos ES6. Tú mismo dijiste que estás usando Babel. Babel convierte importy exportdeclara a CommonJS ( require/module.exports ) de forma predeterminada de todos modos. Entonces, incluso si usa la sintaxis del módulo ES6, usará CommonJS debajo del capó si ejecuta el código en Node.

Existen diferencias técnicas entre los módulos CommonJS y ES6, por ejemplo, CommonJS le permite cargar módulos dinámicamente. ES6 no permite esto, pero hay una API en desarrollo para eso .

Como los módulos ES6 son parte del estándar, los usaría.

Hay varios usos / capacidades que puede considerar:

Exigir:

• Puede tener una carga dinámica donde el nombre del módulo cargado no está predefinido / estático, o donde carga condicionalmente un módulo solo si es "realmente necesario" (dependiendo de cierto flujo de código).
• La carga es sincrónica. Eso significa que si tiene múltiples correos requireelectrónicos, se cargan y procesan uno por uno.

Importaciones ES6:

• Puede usar importaciones con nombre para cargar selectivamente solo las piezas que necesita. Eso puede ahorrar memoria.
• La importación puede ser asíncrona (y en el actual ES6 Module Loader, de hecho lo es) y puede funcionar un poco mejor.

Además, el sistema del módulo Requerir no está basado en estándares. Es muy poco probable que se convierta en estándar ahora que existen módulos ES6. En el futuro habrá soporte nativo para módulos ES6 en varias implementaciones, lo que será ventajoso en términos de rendimiento.

Las principales ventajas son sintácticas:

• Más sintaxis declarativa / compacta
• Los módulos ES6 básicamente harán que UMD (Universal Module Definition) quede obsoleto, esencialmente elimina el cisma entre CommonJS y AMD (servidor vs navegador).

Es poco probable que vea beneficios de rendimiento con los módulos ES6. Aún necesitará una biblioteca adicional para agrupar los módulos, incluso cuando haya compatibilidad total con las funciones de ES6 en el navegador.

¿Hay algún beneficio de rendimiento al usar uno sobre el otro?

La respuesta actual es no, porque ninguno de los motores de navegador actuales se implementa import/exportdesde el estándar ES6.

Algunos cuadros de comparación http://kangax.github.io/compat-table/es6/ no tienen esto en cuenta, así que cuando vea casi todos los verdes para Chrome, tenga cuidado. importLa palabra clave de ES6 no se ha tenido en cuenta.

En otras palabras, los motores de navegador actuales, incluido V8, no pueden importar archivos JavaScript nuevos desde el archivo JavaScript principal a través de ninguna directiva JavaScript.

(Es posible que aún nos falten algunos errores o que falten años para que V8 lo implemente de acuerdo con la especificación ES6).

Este documento es lo que necesitamos, y este documento es lo que debemos obedecer.

Y el estándar ES6 decía que las dependencias del módulo deberían estar allí antes de leer el módulo como en el lenguaje de programación C, donde teníamos (encabezados) .h archivos .

Esta es una estructura buena y bien probada, y estoy seguro de que los expertos que crearon el estándar ES6 lo tenían en cuenta.

Esto es lo que permite a Webpack u otros paquetes de paquetes optimizar el paquete en algunos casos especiales y reducir algunas dependencias del paquete que no son necesarias. Pero en casos tenemos dependencias perfectas, esto nunca sucederá.

Necesitará algo de tiempo hasta que se import/exportactive el soporte nativo, y la requirepalabra clave no irá a ningún lado durante mucho tiempo.

¿Qué es require?

Esta es la node.jsforma de cargar módulos. ( https://github.com/nodejs/node )

El nodo utiliza métodos de nivel de sistema para leer archivos. Básicamente confías en eso cuando lo usas require. requirefinalizará en alguna llamada al sistema como uv_fs_open(depende del sistema final, Linux, Mac, Windows) para cargar el archivo / módulo de JavaScript.

Para comprobar que esto es cierto, intente usar Babel.js y verá que la importpalabra clave se convertirá en require.

El uso de módulos ES6 puede ser útil para 'sacudir árboles'; es decir, habilitar Webpack 2, Rollup (u otros paquetes) para identificar rutas de código que no se usan / importan y, por lo tanto, no se incluyen en el paquete resultante. Esto puede reducir significativamente el tamaño de su archivo al eliminar el código que nunca necesitará, pero con CommonJS se incluye de forma predeterminada porque Webpack et al no tienen forma de saber si es necesario.

Esto se realiza mediante análisis estático de la ruta del código.

Por ejemplo, usando:

import { somePart } 'of/a/package';

... le da al paquete una pista que package.anotherPartno es necesaria (si no se importa, no se puede usar, ¿verdad?), por lo que no se molestará en agruparlo.

Para habilitar esto para Webpack 2, debe asegurarse de que su transpiler no esté escupiendo módulos CommonJS. Si está utilizando el es2015complemento con babel, puede deshabilitarlo de la .babelrcmisma manera:

{
  "presets": [
    ["es2015", { modules: false }],
  ]
}

El paquete acumulativo y otros pueden funcionar de manera diferente: vea los documentos si está interesado.

Cuando se trata de una carga asíncrona o tal vez lenta, import ()es mucho más potente. Vea cuándo requerimos el componente de manera asíncrona, luego lo usamos importde alguna manera asíncrona como en el constuso de variables await.

const module = await import('./module.js');

O si quieres usar require()entonces,

const converter = require('./converter');

La cosa es en import()realidad asíncrona en la naturaleza. Como lo menciona neehar venugopal en ReactConf , puede usarlo para cargar dinámicamente componentes de reacción para la arquitectura del lado del cliente.

También es mucho mejor cuando se trata de enrutamiento. Esa es la única cosa especial que hace que el registro de red descargue una parte necesaria cuando el usuario se conecta a un sitio web específico a su componente específico. por ejemplo, la página de inicio de sesión antes del tablero no descargará todos los componentes del tablero. Porque lo que se necesita actual es decir, el componente de inicio de sesión, que solo se descargará.

Lo mismo ocurre con export: ES6 exportson exactamente iguales que para CommonJS module.exports.

NOTA - Si está desarrollando un proyecto node.js, entonces debe usarlo estrictamente require()como nodo arrojará un error de excepción como invalid token 'import'si fuera a usar import. Por lo tanto, el nodo no admite declaraciones de importación.

ACTUALIZACIÓN: según lo sugerido por Dan Dascalescu : desde v8.5.0 (lanzado en septiembre de 2017), le node --experimental-modules index.mjspermite usar importsin Babel. Se puede (y debe) también publicar sus paquetes MNP ESModule nativa, con compatibilidad hacia atrás para la edadrequire manera.

Consulte esto para obtener más autorización sobre dónde usar las importaciones asíncronas: https://www.youtube.com/watch?v=bb6RCrDaxhw

Lo más importante que debe saber es que los módulos ES6 son, de hecho, un estándar oficial, mientras que los módulos CommonJS (Node.js) no lo son.

En 2019, los módulos ES6 son compatibles con el 84% de los navegadores. Si bien Node.js los coloca detrás de un indicador --experimental-modules , también hay un conveniente paquete de nodos llamado esm , que hace que la integración sea fluida.

Otro problema que es probable que encuentre entre estos sistemas de módulos es la ubicación del código. Node.js supone que la fuente se mantiene en un node_modulesdirectorio, mientras que la mayoría de los módulos ES6 se implementan en una estructura de directorio plana. No es fácil conciliarlos, pero se puede hacer pirateando su package.jsonarchivo con scripts de instalación previos y posteriores. Aquí hay un ejemplo de módulo isomorfo y un artículo que explica cómo funciona.

Personalmente uso la importación porque, podemos importar los métodos requeridos, miembros, usando la importación.

import {foo, bar} from "dep";

FileName: dep.js

export foo function(){};
export const bar = 22

El crédito va a Paul Shan. Más información .

A partir de ahora la importación de ES6, la exportación siempre se compila a CommonJS , por lo que no hay ningún beneficio al usar uno u otro. Aunque se recomienda el uso de ES6, ya que debería ser ventajoso cuando se lanza el soporte nativo de los navegadores. La razón es que puede importar parciales de un archivo, mientras que con CommonJS debe requerir todo el archivo.

ES6 → import, export default, export

CommonJS → require, module.exports, exports.foo

A continuación se muestra el uso común de esos.

Exportación ES6 predeterminada

// hello.js
function hello() {
  return 'hello'
}
export default hello

// app.js
import hello from './hello'
hello() // returns hello

ES6 exporta múltiples e importa múltiples

// hello.js
function hello1() {
  return 'hello1'
}
function hello2() {
  return 'hello2'
}
export { hello1, hello2 }

// app.js
import { hello1, hello2 } from './hello'
hello1()  // returns hello1
hello2()  // returns hello2

CommonJS module.exports

// hello.js
function hello() {
  return 'hello'
}
module.exports = hello

// app.js
const hello = require('./hello')
hello()   // returns hello

Módulo CommonJS exporta múltiples

// hello.js
function hello1() {
  return 'hello1'
}
function hello2() {
  return 'hello2'
}
module.exports = {
  hello1,
  hello2
}

// app.js
const hello = require('./hello')
hello.hello1()   // returns hello1
hello.hello2()   // returns hello2

No estoy seguro de por qué (probablemente optimización - ¿carga lenta?) Funciona así, pero he notado que es importposible que no analice el código si no se utilizan módulos importados.
Lo cual puede no ser un comportamiento esperado en algunos casos.

Tome la odiada clase Foo como nuestra dependencia de muestra.

foo.ts

export default class Foo {}
console.log('Foo loaded');

Por ejemplo:

index.ts

import Foo from './foo'
// prints nothing

index.ts

const Foo = require('./foo').default;
// prints "Foo loaded"

index.ts

(async () => {
    const FooPack = await import('./foo');
    // prints "Foo loaded"
})();

Por otra parte:

index.ts

import Foo from './foo'
typeof Foo; // any use case
// prints "Foo loaded"