Build Awesome (Eleventy): ein Verzeichnis voller Vorlagen, zwei npm-Pakete
Ein einfacherer Site-Generator. Wandelt ein Verzeichnis von Vorlagen (verschiedener Art) in HTML um.
Auf einen Blick
- Was ist das?
- 11ty/buildawesome wandelt ein Verzeichnis mit Vorlagen in HTML um und tritt dabei unter zwei Paketnamen auf, @awesome.me/buildawesome und @11ty/eleventy. Der Beitrag ordnet die Unterstützung für Vorlagensprachen, die vier Testumgebungen und den Alpha-Stand der Version 4 ein.
- Für wen ist es gedacht?
- Passend ist Build Awesome für Projekte, die ein vorhandenes Vorlagenverzeichnis in HTML überführen wollen und Node als Werkzeugkette akzeptieren, insbesondere wenn Liquid oder Nunjucks bereits im Einsatz sind. Weniger passend ist es für Vorhaben, die einen stabilen Hauptzweig brauchen, denn die jüngsten Releases tragen Alpha-Kennungen bis v4.0.0-alpha.10.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Zwei npm-Pakete für denselben Generator: @awesome.me/buildawesome und @11ty/eleventy
Das Repository trägt den Namen 11ty/buildawesome, das README überschreibt es mit Build Awesome (Eleventy). Beschrieben wird ein einfacher statischer Site-Generator, eine Alternative zu Jekyll, geschrieben in JavaScript. Die Beschreibung in den Metadaten bringt es auf eine Zeile: Ein Verzeichnis mit Vorlagen unterschiedlicher Typen wird in HTML umgewandelt.
Im Installationsabschnitt stehen zwei Befehle. Der erste lautet npm install @awesome.me/buildawesome --save-dev, der zweite npm install @11ty/eleventy --save-dev und ist ausdrücklich als abwärtskompatible Variante markiert. Das README erklärt nicht, welcher Name künftig der maßgebliche ist, noch, wie lange die Kompatibilitätszusage gilt.
Diese Unklarheit hat Folgen für die tägliche Arbeit. In einer package.json, die heute @11ty/eleventy führt, steht morgen womöglich ein Paketname, den niemand bewusst gewählt hat. Wer Dependencies inventarisiert, sollte beide Namen kennen und die Umstellung bewusst terminieren, statt sie beim nächsten npm update mitzunehmen.
HTML, Markdown, Liquid, Nunjucks: was die Vorlagen-Engine von Build Awesome annimmt
Die Liste der direkt unterstützten Formate ist kurz und konkret. Das README nennt HTML, Markdown, JavaScript, Liquid und Nunjucks. Für alles Weitere verweist es auf Addons, namentlich für WebC, Sass, Vue, Svelte, TypeScript und JSX, ergänzt um ein vages und viele weitere.
Welche Addons das im Einzelnen sind, wie viele es gibt und wie man sie einbindet, steht im README nicht. Der Plugin-Abschnitt besteht aus einer einzigen Zeile, die auf die Dokumentationsseite zu Plugins unter 11ty.dev weiterleitet. Wer wissen will, ob ein bestimmter Präprozessor verfügbar ist, kommt an dieser externen Seite nicht vorbei.
Das ist eine Redaktionsentscheidung, kein Mangel an Funktion. Für die Einschätzung des Projekts heißt es aber: Die im README genannte Formatliste ist eine Untergrenze, keine Obergrenze. Der tatsächliche Umfang liegt außerhalb des Repositorys und damit außerhalb dessen, was man hier prüfen kann.
Vom Installationsbefehl zur laufenden Site: was das README auslässt
Zwischen Installation und fertiger Site klafft im README eine Lücke. Es zeigt npm install für beide Paketnamen und später npm test für die Testsuiten. Ein Befehl, der aus dem Vorlagenverzeichnis HTML erzeugt oder eine lokale Vorschau startet, taucht im Abschnitt nicht auf.
Stattdessen verweist das README auf einen externen Getting-Started-Leitfaden unter 11ty.dev. Für einen Einsteiger bedeutet das einen Bruch: Nach der Installation verlässt man das Repository und arbeitet in der Websitedokumentation weiter. Wer Build Awesome in eine bestehende Buildkette einhängen will, muss den Einstiegsbefehl dort nachschlagen.
Immerhin ist der Testeinstieg dokumentiert. npm test stößt die Suiten an, deren Aufteilung im nächsten Abschnitt steht. Wer einen Fork betreut, hat damit eine schnelle Rückmeldung, ob eine Änderung die Erwartungen des Projekts verletzt.
ava, Node.js-Test-Runner und Vitest im Browser-Modus: vier Testumgebungen unter npm test
Das Projekt verteilt seine Tests auf vier Umgebungen, die das README mit jeweils eigener Begründung aufführt. ava läuft als primäre Suite im Verzeichnis test und bringt eine eigene Sammlung von Zusicherungen mit. Der eingebaute Node.js-Test-Runner bildet die sekundäre Suite unter test_node. Vitest im Browser-Modus deckt browsernahe Fälle in packages/browser/test ab.
Die vierte Umgebung ist kein Testframework, sondern ein eigenes Repository. 11ty/buildbenchmark dient laut README dem Erkennen von Leistungsregressionen. Dass Build-Geschwindigkeit als eigene Fehlerklasse behandelt wird, sagt einiges über die Prioritäten des Projekts: Ein Generator, der bei jeder Änderung langsamer wird, verliert seinen Zweck.
Die Ausführung läuft über Continuous Integration auf GitHub Actions. Die Testabdeckung wird nicht als Zahl angegeben, sondern über ein eigenes Dokument unter docs/coverage.md verlinkt. Wer eine Prozentzahl sucht, muss dort nachsehen.
Enhancement Queue und Bug-Label: wie 11ty Prioritäten aus der Community zieht
Statt eines festen Release-Plans beschreibt das README einen öffentlichen Rückkopplungsmechanismus. Funktionswünsche werden in einer GitHub-Discussions-Kategorie namens Enhancement Queue gesammelt, in der abstimmbar ist. Offene Fehler werden als Issues mit dem Label bug geführt und nach der Zahl der Reaktionen sortiert.
Beides ist als Sichtbarmachung von Interesse gedacht, nicht als Zusage. Das README formuliert keine Verbindung zwischen Stimmenzahl und Umsetzung, nennt keine Fristen und verspricht keine Reihenfolge. Ein Wunsch mit vielen Stimmen bleibt ein Wunsch mit vielen Stimmen.
Für die Planung eines eigenen Projekts heißt das: Wer auf eine Funktion wartet, findet im Repository keine belastbare Aussage, ob und wann sie kommt. Der ehrliche Weg führt über die Diskussion selbst, nicht über einen Zeitplan, den es hier nicht gibt.
v4.0.0-alpha.10 und der Veröffentlichungstakt im Juli 2026
Die jüngsten Releases tragen ausnahmslos Alpha-Kennungen. v4.0.0-alpha.8 erschien am 18. Juni 2026, v4.0.0-alpha.9 am 1. Juli 2026 um 17:00 UTC, v4.0.0-alpha.10 am selben Tag um 20:56 UTC. Der letzte Push des Repositorys datiert vom 1. Juli 2026.
Zwei Alpha-Veröffentlichungen innerhalb von knapp vier Stunden deuten auf eine heiße Korrektur hin, nicht auf einen geplanten Zyklus. Das README selbst erläutert den Alpha-Stand nicht und nennt kein Datum für eine stabile Version 4.
Wer Build Awesome produktiv einsetzt, steht damit vor einer Wahl. Entweder man bleibt auf der letzten stabilen Linie, die in diesem Ausschnitt nicht genannt wird, oder man nimmt Alpha-Stände in Kauf und damit die Möglichkeit, dass sich zwischen zwei Stunden noch etwas ändert. Für ein privates Vorhaben ist das vertretbar, für eine Site mit Zusagen schwer zu begründen.
Jekyll als Bezugsgröße: wo der Umstieg auf Node sitzt und wo nicht
Das README nennt Jekyll ausdrücklich als das Werkzeug, zu dem Build Awesome eine Alternative sein will. Der Unterschied liegt in der Werkzeugkette. Jekyll stammt aus der Ruby-Welt, Build Awesome ist in JavaScript geschrieben. Wer bereits Node für Build, Linting oder Tests einsetzt, ersetzt damit eine zweite Sprachlaufzeit durch keine.
Der zweite Unterschied betrifft die Vorlagensprache. Jekyll arbeitet mit Liquid, und Liquid wird von Build Awesome laut README direkt unterstützt. Ein Umzug vorhandener Vorlagen ist damit zumindest sprachlich kein Neubau, wenngleich Verzeichnisstruktur und Konfiguration eigene Arbeit bleiben. Warnung: Das README bestätigt die Unterstützung für Liquid, nicht aber eine Kompatibilität mit Jekyll-Projekten im Ganzen.
Die MIT-Lizenz der Repository-Metadaten erlaubt Einbindung und Weiterverarbeitung auch in kommerziellen Projekten, sofern der Lizenztext mitgeführt wird. Für die Prüfung nach der Installation eignet sich npm test im geklonten Repository: Schlagen die Suiten unter test/, test_node/ und packages/browser/test/ fehl, liegt das Problem in der Umgebung und nicht im eigenen Vorlagenverzeichnis.
Redaktionelles Fazit
Passend ist Build Awesome für Projekte, die ein vorhandenes Vorlagenverzeichnis in HTML überführen wollen und Node als Werkzeugkette akzeptieren, insbesondere wenn Liquid oder Nunjucks bereits im Einsatz sind. Weniger passend ist es für Vorhaben, die einen stabilen Hauptzweig brauchen, denn die jüngsten Releases tragen Alpha-Kennungen bis v4.0.0-alpha.10. Vor der Festlegung gehört eine Prüfung: Den Installationsbefehl gegen das eigene Node-Release laufen lassen, npm test ausführen und anschließend im Repository nachsehen, welcher der beiden Paketnamen in der Installationsanleitung zuerst genannt wird.
Community-Notizen