Mit Javascript unter Node.js entwickeln Cheat Sheet

Node.js ist eine Entwic­klungs- und Laufze­itu­mgebung für Javascript

Es wird ähnlich wie das Java SDK mit einer Standa­rdb­ibl­iothek ausgel­iefert deren Module in der Node API Dokume­ntation beschr­ieben sind. Diese Bibliothek steht nur zur Entwic­klu­ngszeit oder bei der Ausführung auf dem Server (auf welchem Node.js läuft) zur Verfügung. Zur Laufzeit im Browser steht diese Bibliothek nicht zur Verfügung.

Node.js nutzt zum Compil­ieren der Javascript Dateien den Compiler V8. Dieser compiliert direkt in Maschi­nenkode (also früher z.B. x86 oder MIPS).
Im Chrome Browser kommt der V8 Compiler ebenfalls zum Einsatz.

Node.js wird stets in 2 Releases bereit­ges­tellt (April und Oktober Release). Ein Release trägt dabei im Namen den Zusatz LTS (Long time support). Dieses eignet sich für den produk­tiven Einsatz. Für dieses Release werden ab Veröff­ent­lichung ca. 30 Monate Bugfixes und sonstige Unters­tützung angeboten. Das andere Release wird nur 6 Monate supported.

Grunds­ätzlich läuft Entwic­kle­rkode in Node.js nur Single­thr­eaded ab aber Node.js selbst ist Multit­hre­aded. Dem Entwickler steht halt nur ein Thread zur Verfügung. Um auf etwas zu warten oder zu pausieren stehen Konstrukte wie: setTimeout und setInt­ervall zur Verfügung. Der Trick dabei ist, dass dies Konstrukte nicht blocki­eren.

Grundl­egende Befehle
# Node.js Version heraus­­finden
>node -v

# Node.js im intera­ktiven Mode starten
>node

# Node.js zur Ausführung einer Datei starten
>node app.js

Lokali­sierung (l10n) und i18n
Die Lokali­sierung von Angular Anwend­ungen entspr­echend den Angular Vorgaben erfolgt durch separat zu bauende Anwend­ungen für jede Sprache eine (nebst neuer Compil­ierung und Bündel­ung).
Die Texte werden dabei ausgel­agert in separaten Dateien gehalten. Die Zuordnung der Texte zur Verwendung im Programm erfolgt über IDs. Sollen im HTML bestimmte Attribute mit lokali­sierten Texten beladen werden so sind nach einer vordef­ini­erten Syntax die Schlüssel dort anzugeben. Weiterhin muss bekann­tge­geben werden welches Attribut ein i18n Attribut ist. Dazu wird das Attribut wiederholt und der Prefix i18n- vorang­est­ellt. Handelt es sich bei dem Attribut leider um einen Input Parameter (@Input) welcher durch [] ausged­rückt wird, so funkti­oniert diese Ersetzung nicht. Hier hilft nur das Auflösen der [] und die Verwendung der Canoni­schen Form. Dadurch funkti­oniert der i18n Mechan­ismus als wäre der Attrib­utwert ein Text und außerdem wird der Wert an die Komponente als Input Wert reinge­reicht.
Proble­mösung siehe hier: https:­//s­tac­kov­erf­low.co­m/q­ues­tio­ns/­432­026­00/­how­-to­-us­e-a­ngu­lar­2-i­18n­-x-­to-­loc­ali­ze-­pro­per­tie­s-c­ons­tan­t-v­alu­e?a­nsw­ert­ab=­vot­es#­tab-top

Testfr­ame­works

~, stellen oft einen Testrunner und eine Assertion Library zur Verfügung.

Jasmine ältestes Framework, aus der Browse­rum­gebung kommend nun durch Node auch im Server­umfeld gelandet. Beinhaltet Testrunner und Assert­ions.
Mocha das zweit älteste Framework, von Node.js her kommend lässt es sich inzwischen auch im Browser verwenden (https­://­med­ium.co­m/d­ail­yjs­/ru­nni­ng-­moc­ha-­tes­ts-­as-­nat­ive­-es­6-m­odu­les­-in­-a-­bro­wse­r-8­823­73f­2ecb0).
Ava, ein recht junges Framework welches Wert auf konseq­uente asynchrone Testau­sfü­hrung legt. In Spezia­lfällen (Singleton etc.) schwie­riger handha­bbar.

Assertion Frameworks
Assert Modul: Wird direkt von Node.js bereit­ges­tellt
assert­that: Bietet ein Fluent API
should.js Schöne Schrei­bweise aber in Spezia­lfällen bei denen das actual undefined ist, ist der Einsatz schwierig.
* expect.js Schick

Versio­nierung
Details unter: https:­//f­lav­ioc­ope­s.c­om/­pac­kag­e-j­son­/#p­ack­age­-ve­rsions

^: Die angegebene Version mit Minorä­nde­rungen aber keine Majorä­nde­rungen
~: Die angegebene Version mit Patches
* : Alle Versionen
>: Alle Versionen größer als die angegebene
>=: Alle Versionen größer oder gleich der angege­benen
<=: Alle Versionen kleiner oder gleich der angege­benen
X.Y.Z: Exakte Versio­nsa­ngabe und nur diese Version wird benutzt
latest: Stets die aktuellste Version ist zu laden.
<: Alle Versionen kleiner der angege­benen

Module

Die weltweite Registry für npm Module befindet sich unter: npmjs.com
Wer hier Module ablegen will benötigt ein Login und muss sich regist­rieren.

# Ein eigenes Node.js Modul auf npmjs.com veröff­ent­lichen
>npm login
>npm publish


# Ein eigenes Node.js Modul von npmjs.com zurück­ziehen
# nur 24 h lang möglich - danach geht es nur noch über den Support
# lessons learned aus dem left-pad disaster
>npm unpublish [<@­sco­pe>­/]<­pkg­>[@­<ve­rsi­on>]

# Das Grundg­erüst für ein eigenes Node.js Modul interaktiv erstellen
>npm init


Modul- (oder Projekt) Metadaten werden in der Datei packag­­e.json verwaltet (wie bei maven die pom.xml).
Hier wird der Name und die Version des Moduls angegeben, seine Abhäng­igk­eiten, seine Abhäng­igk­eiten zur Entwic­klu­ngszeit und es gibt einen Script Abschnitt in dem Aliase für die Ausführung von Befehlen hinterlegt werden können z.B. um bestimmte Build Schritte anzustoßen wie npm run test um die Unittests auszuf­ühren.
Es existiert weiterhin ein Verzei­chnis node_m­odules in dem alle Abhäng­igk­eiten des Modules abgelegt werden (auch die transi­tiven).
Ladere­ihe­nfolge: Ein zu ladendes Modul wird von Node.js wie folgt gesucht; 1, Integr­iertes Modul (Module der Node.js Standa­rdlib) 2. instal­lierte Module (durch npm install im node_m­odules Verzei­chnis abgelegt) 3. eigenes, entwic­keltes Modul. - Diese Reihen­folge soll sicher­ste­llen, dass kein Schadkode als transitive Abhäng­igkeit einges­chleußt werden kann.
Versio­nierung Node.js Module verwenden eine semant­ische Versio­nie­rung.

# Hier lädt node.js das http Modul und gibt eine Referenz darauf zurück
http = requir­e('h­ttp­');

Frage: Ist require nur in node.js definiert oder auch in Javascript also auch im Browser und ist es zustät­zlich auch in angular oder typescript nutzbar?
Antwort: require() is not part of the standard JavaScript API. But in Node.js, it's a built-in function with a special purpose: to load modules. (Quelle: https:­//s­tac­kov­erf­low.co­m/q­ues­tio­ns/­990­108­2/w­hat­-is­-th­is-­jav­asc­rip­t-r­equire)

Falsche Kombin­ation Runner - Assert

Die Testrunner sorgen dafür, dass die Tests aus den Testda­teien gefunden und ausgeführt werden. Die Assertion Frameworks prüfen Tester­geb­nisse und werfen bei nicht zutref­fenden Beding­ungen eine Exception. Diese Exception muss der Testrunner erwarten, sonst bleibt der Test grün. Es ist also wichtig, dass das genutzte Assertion Framework eine zum Testrunner passende Exception wirft. Das ist in der Regel so, in Sonder­fällen muss man aber nachlesen.

Asynchrone Tests

Als Asynchrone Tests bezeichnen wir hier Tests welche mindestens eine Zeile enthalten in der eine Promise entsteht, das Kommando also sofort zurück­kehrt, das Ergebnis aber noch nicht vorliegt sondern nur die Promise als Versic­herung, dass es mal irgendwann ein Ergebnis geben wird.
Solche Tests werden in der Regel mit async gekenn­zei­chnet und es wird in aller Regel auch ein callback (done) hinein­geg­eben, welches man selbst nach dem letzten Assert aufrufen muss. Ruft man das callback nicht auf zum Beispiel weil man den Test gar nicht als async gekenn­zei­chnet hat, betrachtet der Testrunner den Testfall nach dem letzten Assert als beendet auch wenn noch einige Promises gar nicht aufgelöst wurden. Er kennze­ichnet den Test grün und wenn dann später noch eine Promise resolved wird - ändert dies das Tester­gebnis nicht mehr.
Daher ist es sinnvoll pauschal alle Tests in der async Variante zu implem­ent­ieren und ideale­rweise eine solche Abarbe­itung zu erzwingen. Bei Mocha geht dies mit der Option --asyn­c-only