Aprende a dividir código en archivos reutilizables con export/import, evitando dependencias ocultas y mejorando mantenibilidad, pruebas y escalabilidad.
Cuando todo vive en un solo archivo, el proyecto crece rápido en complejidad y baja la confianza para tocar código.
ESM (ECMAScript Modules) permite separar responsabilidades en piezas pequeñas y explícitas con export/import.
Esto mejora lectura, pruebas, reutilización y reduce acoplamiento accidental entre partes de la aplicación.
Objetivo de esta lección: estructurar módulos claros y decidir cuándo usar exportaciones nombradas o por defecto.
Un módulo no es solo un archivo: es un contrato claro con el resto del sistema.
Piensa cada módulo como una caja con API pública definida. Lo que exportas es lo único que otras piezas deberían conocer.
Cuando separas lógica por dominio (formatos, validaciones, API, UI), el mantenimiento deja de depender de memoria personal.
Define qué sale del módulo y qué entra desde otros módulos.
Las exportaciones nombradas son ideales cuando un archivo ofrece varias utilidades (`export function ...`, `export const ...`).
La importación debe ser explícita para que el lector entienda dependencias sin recorrer todo el proyecto.
Ambos son válidos, pero cada uno tiene un contexto más claro.
Usa named exports cuando un módulo ofrece varias piezas o cuando quieres autocompletado/renombrado más explícito.
Usa default export cuando el módulo representa una única entidad principal (por ejemplo, una clase o función central).
ESM es el estándar, pero el contexto de ejecución importa.
En navegador, para usar módulos debes cargar scripts con `type=module`. En Node, depende de extensión/configuración (`.mjs` o `type: module`).
Comprender este detalle evita errores típicos como rutas incorrectas o mensajes de import no soportado.
Si aplicas estas reglas, tu base de código será más fácil de evolucionar.
Una buena modularización no persigue archivos mínimos, sino límites claros entre responsabilidades.
Antes de crear más módulos, valida si cada uno aporta cohesión y evita acoplamiento innecesario.
Aprende a dividir código en archivos reutilizables con export/import, evitando dependencias ocultas y mejorando mantenibilidad, pruebas y escalabilidad.
Código del tema: export · import · default export · named export
Un módulo no es solo un archivo: es un contrato claro con el resto del sistema.
Piensa cada módulo como una caja con API pública definida. Lo que exportas es lo único que otras piezas deberían conocer.
Cuando separas lógica por dominio (formatos, validaciones, API, UI), el mantenimiento deja de depender de memoria personal.
Define qué sale del módulo y qué entra desde otros módulos.
Las exportaciones nombradas son ideales cuando un archivo ofrece varias utilidades (`export function ...`, `export const ...`).
La importación debe ser explícita para que el lector entienda dependencias sin recorrer todo el proyecto.
Ambos son válidos, pero cada uno tiene un contexto más claro.
Usa named exports cuando un módulo ofrece varias piezas o cuando quieres autocompletado/renombrado más explícito.
Usa default export cuando el módulo representa una única entidad principal (por ejemplo, una clase o función central).
ESM es el estándar, pero el contexto de ejecución importa.
En navegador, para usar módulos debes cargar scripts con `type=module`. En Node, depende de extensión/configuración (`.mjs` o `type: module`).
Comprender este detalle evita errores típicos como rutas incorrectas o mensajes de import no soportado.
Si aplicas estas reglas, tu base de código será más fácil de evolucionar.
Una buena modularización no persigue archivos mínimos, sino límites claros entre responsabilidades.
Antes de crear más módulos, valida si cada uno aporta cohesión y evita acoplamiento innecesario.