La forma en que se manejan las exportaciones en los módulos ES (ECMAScript Modules) es un pilar fundamental para comprender su comportamiento, especialmente al interactuar con datos mutables o inmutables. En esencia, la distinción clave radica en que una exportación nombrada (export) proporciona un binding o enlace directo a la variable original, similar a una referencia o alias, mientras que una exportación por defecto (export default) expone una copia del valor de la variable en el momento de la exportación.

Esta diferencia explica por qué intentar exportar directamente un valor literal mediante una exportación nombrada resultará en un error de sintaxis, mientras que export default lo permite sin problemas. Para que el motor JavaScript pueda crear un binding, necesita una declaración de variable (var, let, const, function, class) que le proporcione una "dirección" o "manejador" al cual enlazar. Un literal por sí solo no tiene esta "dirección" permanente en el ámbito del módulo.

Además, es importante notar que el contenido de un módulo solo puede ser modificado dentro de ese módulo. Desde fuera, los módulos importados se comportan como si sus variables exportadas (nombradas) fueran constantes a nivel superficial. Esto significa que no se puede reasignar un binding importado, pero sí se pueden modificar las propiedades de objetos importados, lo cual es una forma de "protección superficial".

Ejemplos Prácticos

A continuación, exploraremos esta dinámica con una serie de módulos interconectados. Los cambios en el módulo base se reflejarán o no en los módulos importadores, dependiendo del tipo de exportación.

moduloBase.js

// moduloBase.js
export let contadorGlobal = 100;

export const ajustesAplicacion = {
    version: '1.0',
    tema: 'claro'
};

let mensajePrincipal = "Hola desde el módulo base";
export default mensajePrincipal;

export function actualizarValores(nuevoContador, nuevoMensaje) {
    contadorGlobal = nuevoContador;
    // Esta modificación solo afecta a la variable 'mensajePrincipal'
    // dentro de este módulo. La importación por defecto en otros módulos
    // ya recibió una copia del valor original.
    mensajePrincipal = nuevoMensaje;
}

testActualizacion.js

// testActualizacion.js
import textoDefecto, { contadorGlobal, actualizarValores, ajustesAplicacion } from './moduloBase.js';

console.log(`[testActualizacion.js] Inicial: Contador=${contadorGlobal}, Tema=${ajustesAplicacion.tema}, TextoDefecto="${textoDefecto}"`);

setTimeout(() => {
    // Modificamos una propiedad del objeto importado. Esto es posible debido a la protección superficial.
    ajustesAplicacion.tema = 'oscuro';
    // Llamamos a una función exportada para modificar variables en el módulo base.
    actualizarValores(250, 'Mensaje actualizado internamente');

    console.log(`[testActualizacion.js] Después de Actualizar: Contador=${contadorGlobal}, Tema=${ajustesAplicacion.tema}, TextoDefecto="${textoDefecto}"`);
}, 100);

testObservador.js

// testObservador.js
import miTextoDefecto, { contadorGlobal, ajustesAplicacion } from './moduloBase.js';

console.log(`[testObservador.js] Inicial: Contador=${contadorGlobal}, Tema=${ajustesAplicacion.tema}, MiTextoDefecto="${miTextoDefecto}"`);

setTimeout(() => {
    // Observamos los cambios realizados por testActualizacion.js
    console.log(`[testObservador.js] Después de Observar: Contador=${contadorGlobal}, Tema=${ajustesAplicacion.tema}, MiTextoDefecto="${miTextoDefecto}"`);
}, 150); // Ejecutamos un poco después para capturar los cambios del otro módulo

appPrincipal.js

// appPrincipal.js
import './testActualizacion.js';
import './testObservador.js';

Al ejecutar appPrincipal.js, la salida en la consola ilustrará los siguientes puntos:

• El valor de contadorGlobal reflejará el cambio en ambos módulos (testActualizacion.js y testObservador.js). Esto valida que export let contadorGlobal exporta un binding vivo; cualquier módulo que lo importe tiene un enlace a la misma instancia de la variable en el módulo base.
• La propiedad ajustesAplicacion.tema también mostrará el cambio en ambos módulos. Esto demuestra la protección superficial: aunque no podemos reasignar ajustesAplicacion (ya que el binding es constante), sí podemos modificar sus propiedades internas, y estos cambios son visibles a través del mismo binding compartido.
• El valor importado por defecto (textoDefecto en testActualizacion.js y miTextoDefecto en testObservador.js) permanecerá inmutable a pesar de que la función actualizarValores modifica la variable mensajePrincipal en moduloBase.js. Esto confirma que export default exporta una copia del valor, no un binding.

Si estos conceptos son claros, la siguiente sección profundiza en los detalles. Si aún hay dudas, la información adicional podría ser útil.

Bindings (Enlaces) y Valores

El término "binding" (o enlace) se refiere a una conexión directa a la ubicación de memoria de una variable declarada en el módulo de origen. Cuando importamos un binding, lo que obtenemos es esencialmente un "manejador" o "referencia" a esa variable. Cualquier operación realizada sobre ese binding (dentro del módulo de origen, o mediante funciones expuestas por el módulo de origen) afecta la variable original, y esos cambios son inmediatamente visibles en todos los módulos que hayan importado ese mismo binding.

Por otro lado, una exportación por defecto proporciona una copia del valor. Si el valor es una primitiva (número, cadena, booleano), se crea una copia directa. Si es un objeto, lo que se copia es la referencia al objeto, no el objeto en sí (a menos que se realice una clonación profunda explícita). Sin embargo, el "binding" de esa referencia importada es fijo, y si la variable original se reasigna en el módulo fuente, la copia importada no se actualizará.

Consideraciones Adicionales

1. Métodos de Declaración de Variables en JavaScript

Para crear un binding que pueda ser exportado, la variable debe ser declarada mediante:

• var, let, const
• function
• class
• import (Aunque import crea un binding a una variable externa, no "declara" una nueva varible en el ámbito local en el mismo sentido que las anteriores. Sin embargo, su comportamiento de binding es fundamental.)

La razón por la que export { 1 } o export { 'hola' } fallaría es que los literales no tienen un binding asociado a una declaración de variable.

Un detalle importante sobre la sintaxis de re-exportación:

// main.js
export { default as miAlias } from './otroModulo.js';

En este caso, la variable miAlias no es accesible directamente en main.js; simplemente actúa como un puente para re-exportar la exportación por defecto de otroModulo.js bajo un nuevo nombre. Si se deseara acceder a ella en main.js, sería necesario importarla primero y luego exportarla:

// main.js
import valorInterno from './otroModulo.js';
export { valorInterno }; // Ahora 'valorInterno' es una exportación nombrada de main.js
// o export default valorInterno; // Si se quiere re-exportar como default

2. Memoria Heap y Stack

• Memoria Stack (Pila): Almacena datos primitivos (números, booleanos, cadenas cortas, null, undefined) y las referencias (punteros) a objetos. Los datos en la pila tienen un tamaño fijo y conocido en tiempo de compilación.
• Memoria Heap (Montón): Almacena datos de tipos de referencia (objetos, arrays, funciones). Estos datos pueden tener un tamaño variable y son asignados y desasignados de forma más dinámica.

La forma en que export y export default manejan los bindings y valores está directamente relacionada con cómo se almacenan las variables en estas áreas de memoria.

Módulos ES vs. CommonJS

1. Diferencias en Implementación

Los Módulos ES son un estándar oficial de ECMAScript, lo que permite su implementación directa a nivel sintáctico en el lenguaje. CommonJS, por otro lado, es una especificación de comunidad (popularizada por Node.js) que se implementa a través de convenciones y envolturas a nivel de antorno de ejecución (por ejemplo, funciones que encapsulan el contenido de cada módulo).

2. Exportaciones Nombradas y por Defecto

En CommonJS, module.exports y exports (que es un alias de module.exports) funcionen esencialmente como un único objeto que el módulo "retorna". Todo lo que se asigna a este objeto se convierte en parte de la interfaz pública del módulo. Por lo tanto, no hay una distinción conceptual entre "bindings" y "valores copiados" de la misma manera que en ES Modules.

En ES Modules, como hemos visto, export y export default tienen una diferencia fundamental: uno exporta un binding, el otro un valor. Esta diferencia se refleja en la sintaxis:

// Exportación nombrada directa
export let miVariable = 1;

// Exportación nombrada con lista (la variable debe existir previamente)
let otraVariable = 2;
export { otraVariable };

Es crucial entender que la sintaxis export { nombre } espera un identificador de una variable existente. Por eso, intentar exportar un literal o una expresión directamente de esta forma fallará:

// Esto causará un SyntaxError: "Unexpected token ':'" o similar
export { valorLiteral: 123 };

Esto ocurre porque el parser de JavaScript espera un identificador después de la llave, no un par clave-valor como en un objeto literal. Si se intenta con identificadores ya declarados:

let x = 1;
export { x };
// let x = 2; // SyntaxError: Identifier 'x' has already been declared
// export let x = 2; // SyntaxError: Duplicate export of 'x'

Incluso con var, que permite re-declaraciones en el mismo ámbito:

var y = 1;
export { y };
// var y = 2; // Esto no daría error en JavaScript normal, pero la combinación de exportaciones sí:
// export var y = 2; // SyntaxError: Duplicate export of 'y'

Esto demuestra que las reglas de exportación de ES Modules son estrictas en cuanto a la unicidad de los bindings exportados y requieren identificadores válidos.

3. Importaciones Dinámicas

CommonJS permite importaciones dinámicas de forma nativa, ya que require() es una función síncrona que se puede llamar en cualquier momento:

const miModulo = require('./ruta/al/modulo.js');

Los Módulos ES introdujeron la importación dinámica como una característica asíncrona que devuelve una promesa, adecuada para cargar módulos bajo demanda:

const cargarModulo = async () => {
    const modulo = await import('./ruta/al/modulo.js');
    console.log(modulo.default, modulo.exportacionNombrada);
};
cargarModulo();

Consideraciones sobre Tree Shaking

Los Módulos ES son intrínsecamente más adecuados para "Tree Shaking" (eliminación de código muerto) que CommonJS. Esto se debe a que las importaciones y exportaciones de ES Modules son estáticas: el analizador puede determinar qué partes de un módulo se utilizan y cuáles no en tiempo de compilación, sin necesidad de ejecutar el código.

El desafío principal para Tree Shaking es identificar y eliminar código sin efectos secundarios. Si un módulo contiene funciones puras, es relativamente sencillo. Sin embargo, si hay efectos secundarios (como modificar el DOM, realizar llamadas de red o escribir en la consola), el bundler debe ser cauteloso para no eliminarlos.

La granularidad que ofrecen las exportaciones nombradas de ES Modules facilita que las herramientas de bundling (como Webpack o Rollup) detecten qué partes específicas de un módulo se están usando. Por esta razón, se recomienda usar ES Modules y exportaciones nombradas para optimizar el Tree Shaking.