es modules

De Node.js-documentatie omschrijft ES modules expliciet als "the official standard format to package JavaScript code for reuse". Dit is geen marketingtaal maar een functionele definitie: ES modules zijn het geaccepteerde formaat voor moderne JavaScript-toepassingen. Ontwikkelaars splitsen code op in logische eenheden, waarbij elke module verantwoordelijk is voor specifieke functionaliteit. Dit bevordert onderhoudbaarheid, testbaarheid en hergebruik van code.

Stappen: ES modules inschakelen in Node.js

Stap 1: Controleer je Node.js-versie

node --version

Voor volledige ondersteuning zonder experimentele waarschuwingen heb je Node.js v14.0.0 of hoger nodig. Vanaf v12.17.0 en v13.2.0 werkt het laden van ES modules zonder command-line vlag, maar toont Node.js nog een 'experimental'-waarschuwing.

Stap 2: Kies je bestandsextensie

Gebruik de `.mjs`-extensie voor modules, of stel `"type": "module"` in in je `package.json`-bestand. De `.mjs`-extensie is de eenvoudigste manier om aan te geven dat een bestand een ES module is.

touch app.mjs

Stap 3: Configureer je package.json

Als je `.js`-bestanden wilt gebruiken voor ES modules, voeg dan het veld `"type"` toe aan je `package.json`:

{
  "name": "mijn-project",
  "version": "1.0.0",
  "type": "module"
}

Dit vertelt Node.js dat alle `.js`-bestanden in het project ES modules zijn. Zonder deze configuratie behandelt Node.js `.js`-bestanden als CommonJS.

Stap 4: Exporteer een functie uit een module

Maak een bestand `utils.mjs` met een export:

export function getServerStatus() {
  return {
    hostname: 'pixzo-server-01',
    status: 'online',
    uptime: process.uptime()
  };
}</p><p>export const config = {
  port: 8080,
  environment: 'production'
};

De `export`-statement maakt functies en variabelen beschikbaar voor andere modules.

Stap 5: Importeer de module in je hoofdscript

Maak een bestand `app.mjs` en importeer de functies:

import { getServerStatus, config } from './utils.mjs';</p><p>console.log('Server status:', getServerStatus());
console.log('Configuratie:', config);

De `import`-statement haalt specifieke exports uit de module. Node.js voert een statische analyse uit van alle `import`- en `export`-statements voordat de code wordt uitgevoerd.

Stap 6: Voer het script uit

node app.mjs

Vanaf Node.js v14.0.0 draait dit zonder waarschuwingen of vlaggen.

Stap 7: Gebruik dynamische imports voor runtime-laden

ES modules ondersteunen dynamische imports via `import()`, wat runtime-laden van modules toestaat:

async function loadModule(moduleName) {
  const module = await import(`./modules/${moduleName}.mjs`);
  return module.default;
}</p><p>const serverModule = await loadModule('server');

Dit is vooral nuttig voor code-splitting en het laden van modules op basis van runtime-condities.

Stap 8: Combineer met CommonJS waar nodig

Voor bestaande CommonJS-projecten kun je een fallback bieden:

// bestand: legacy.cjs
module.exports = {
  getLegacyData() {
    return { format: 'commonjs' };
  }
};

// bestand: modern.mjs
import { createRequire } from 'module';
const require = createRequire(import.meta.url);
const legacy = require('./legacy.cjs');</p><p>console.log(legacy.getLegacyData());

De `createRequire`-functie maakt het mogelijk om CommonJS-modules te laden vanuit een ES module.

Verificatie

Controleer of je project correct werkt met ES modules:

node --input-type=module -e "import { getServerStatus } from './utils.mjs'; console.log(getServerStatus());"

Dit commando draait een ES module direct vanaf de commandoregel. Als je geen foutmelding krijgt en de serverstatus ziet, werken je ES modules correct.

Verschillen met CommonJS

Het verschil tussen ES modules en CommonJS zit niet alleen in syntaxis maar ook in de onderliggende werking. CommonJS laadt synchroon en is gebaseerd op `require()`. ES modules werken asynchroon en zijn gebaseerd op statische analyse van `import`- en `export`-statements.

De statische analyse maakt tree-shaking mogelijk: bundlers zoals Webpack of Vite kunnen ongebruikte code verwijderen. Dit levert kleinere bundles op en betere prestaties. CommonJS biedt dit voordeel niet omdat het laden dynamisch gebeurt.

ES modules werken zowel server-side als client-side. Omdat ze deel uitmaken van de ECMAScript-standaard, ondersteunen moderne browsers dezelfde syntaxis als Node.js. Dit vereenvoudigt full-stack JavaScript-ontwikkeling: dezelfde code of bibliotheken draaien in de browser en op de server.

Veelgestelde problemen

Probleem 1: "Cannot use import statement outside a module"

Dit gebeurt wanneer Node.js een `.js`-bestand als CommonJS behandelt. Los het op door de `.mjs`-extensie te gebruiken of `"type": "module"` toe te voegen aan je `package.json`.

Probleem 2: "ERR_MODULE_NOT_FOUND" bij imports

Dit betekent dat Node.js het modulepad niet kan vinden. Controleer of het pad correct is en of je de bestandsextensie hebt toegevoegd. In tegenstelling tot CommonJS vereisen ES modules altijd de volledige bestandsnaam inclusief extensie:

// Fout - werkt niet
import { config } from './utils';</p><p>// Correct
import { config } from './utils.mjs';

Probleem 3: Experimentele waarschuwing bij oudere Node.js-versies

Als je Node.js v12.17.0 tot v13.14.0 gebruikt, krijg je nog een 'ExperimentalWarning'. Dit is cosmetisch en beïnvloedt de functionaliteit niet. Upgrade naar v14.0.0 of hoger om de waarschuwing te verwijderen.

Historische context

De ondersteuning van ES modules in Node.js kent een geleidelijke ontwikkeling. Node.js versie v8.5.0 introduceerde de eerste experimentele ondersteuning, maar alleen met een command-line vlag. Vanaf v12.0.0 kon je ES modules activeren zonder vlag, mits het bestand de `.mjs`-extensie had of `"type": "module"` in `package.json` stond.

Vanaf v12.17.0 en v13.2.0 werd het laden niet langer afhankelijk van een command-line vlag. De experimentele status bleef zichtbaar via waarschuwingen, maar de functionaliteit was technisch stabiel. De definitieve erkenning kwam met Node.js v14.0.0, plus de backports naar v13.14.0 en v12.20.0. Vanaf deze versies verdween de experimentele waarschuwing volledig.

De ECMAScript-standaard zelf wordt beheerd door Ecma International. De oorsprong van JavaScript ligt bij Brendan Eich, die de taal ontwikkelde bij Netscape onder de naam Mocha, later LiveScript, en uiteindelijk JavaScript. De introductie van modules in de ES2015-specificatie pakte een fundamentele tekortkoming aan: het gebrek aan een ingebouwde manier om code te modulariseren.

Praktische implicaties voor Pixzo-omgevingen

Binnen de context van Pixzo, met focus op Linux, servers, hosting, netwerken, containers en databases, is kennis over ES modules relevant voor iedereen die werkt met moderne JavaScript-toepassingen op de server. Het gebruik van ES modules is geen optionele keuze meer maar een standaardpraktijk in nieuwere projecten. Het beïnvloedt keuzes rond build tools, package managers, deploy processen en compatibiliteit met oudere systemen.

In containeromgevingen draait Node.js vaak als onderdeel van een grotere applicatiestack. De keuze voor ES modules heeft gevolgen voor hoe je je Docker-images bouwt, welke Node.js-versie je baseert, en hoe je je applicatie bundelt voor productie. De statische analyse van ES modules maakt het mogelijk om kleinere bundles te genereren, wat directe voordelen biedt voor container-images: minder opslag, snellere pulls en kortere startup-tijden.

De overgang van CommonJS naar ES modules blijft een actueel onderwerp in de Node.js-gemeenschap. Veel bestaande packages bieden nog steeds CommonJS aan als primair formaat, terwijl nieuwere packages beide formaten ondersteunen via conditional exports in `package.json`. Deze transitieperiode vraagt om bewuste keuzes bij het opzetten van nieuwe projecten en het migreren van bestaande codebases.