Synthese: der Modul-Baukasten

Du kannst jetzt Dateien verbinden. Bleibt die Frage, die dir kein Sprachmittel abnimmt: Welche Dateien soll es überhaupt geben?

Darauf gibt es keine Regel, aber eine Faustregel, die erstaunlich weit trägt.

01 / 04Eine Datei ist die Antwort auf eine Frage

Nicht auf ein Thema, nicht auf einen Ordner, sondern auf eine Frage, die du in einem Satz stellen kannst. „Wie rechne ich Preise?” ist so eine. „Wie formatiere ich Beträge und Tabellenzeilen?” auch.

export function euro(betrag) {
  return betrag.toFixed(2).replace(".", ",") + " EUR";
}

export function tabelle(name, wert) {
  return `${name.padEnd(10)} ${wert}`;
}

import { euro, tabelle } from "./format.mjs";

console.log(tabelle("Kaffee", euro(23.8)));
console.log(tabelle("Versand", euro(4.9)));

format.mjs beantwortet genau eine Frage, und deshalb weißt du beim nächsten Formatierungsproblem sofort, wo du hinschauen musst. Es steht keine Rechenlogik darin und kein Dateizugriff. Wenn du in einem halben Jahr die Währung wechseln willst, ist klar, wo du anfängst.

Der Gegentest ist genauso einfach: Wenn du den Zweck einer Datei nur mit „und” beschreiben kannst, sind es zwei Dateien.

02 / 04Warum utils.js ein Warnsignal ist

Fast jedes Projekt hat irgendwann eine Datei namens utils.js, helpers.js oder common.js. Sie fängt mit zwei Funktionen an und hat nach einem Jahr vierzig.

Das liegt daran, dass sie keine Frage beantwortet. Sie sagt nur: hier liegt, was nirgends anders hinpasste. Und weil man das von jeder neuen Funktion auch behaupten kann, wächst sie immer weiter. Am Ende importiert die halbe Anwendung dieselbe Datei, ohne dass jemand sagen könnte, wofür.

Der Ausweg ist nicht, utils.js zu verbieten. Der Ausweg ist, beim Hineinschreiben kurz zu fragen: Wozu gehört das eigentlich? Meistens fällt dir dann der richtige Name ein, und die Datei entsteht von selbst.

03 / 04Wie ein Programm aus Bausteinen aussieht

Für die Aufgabe gleich liegen drei fertige Module bereit, und die Aufteilung folgt genau dieser Regel:

daten.mjs liefert, was es gibt. preise.mjs macht daraus Zahlen. texte.mjs macht daraus Ausgaben.

Und index.mjs verdrahtet die drei. Diese Datei ist die einzige, die alle drei kennt. Die drei untereinander kennen sich nicht, und genau das macht sie austauschbar: Du kannst die Daten aus einer Datei statt aus einer Liste holen, ohne dass texte.mjs etwas davon merkt.

Diese Aufteilung siehst du in echten Projekten überall wieder. In Abschnitt 18 bekommt sie einen Namen und eine Ordnerstruktur dazu, aber die Idee ist schon hier vollständig.

04 / 04Wenn zwei Dateien sich gegenseitig brauchen

Es gibt einen Fall, bei dem der Schnitt schiefgegangen ist: a.mjs importiert b.mjs, und b.mjs importiert a.mjs.

import { b } from "./b.mjs";

export const a = "A";

console.log("a.mjs sieht b als:", b);

import { a } from "./a.mjs";

export const b = "B";

console.log("b.mjs sieht a als:", a);

import "./a.mjs";

Node bricht dabei nicht in eine Endlosschleife aus, sondern arbeitet die Kette ab und lässt den noch nicht fertigen Teil leer. In ESM merkst du das an einem ReferenceError, weil eine Konstante noch nicht bereitsteht. In CommonJS bekämst du an derselben Stelle ein halb gefülltes Objekt und keinen Fehler, was unangenehmer ist.

Die Meldung Cannot access 'a' before initialization ist deshalb ein ziemlich zuverlässiges Zeichen für einen Ringschluss. Wichtiger als die Meldung ist aber, was sie dir sagt: Wenn zwei Dateien einander brauchen, gehört das Gemeinsame meistens in eine dritte. Diese dritte ist dann übrigens genau die Datei, deren Frage vorher niemand gestellt hat.