Ich betrachte Typoskript innerhalb des Knotens und verwende derzeit Typoskript über die ///<reference.../> -Syntax, die rein interne Module verwendet. Bei größeren Projekten kann dies jedoch unhandlich werden, da Sie Module verwenden können, die auf andere Module verweisen, die alle miteinander verknüpfende Referenzen haben.
Also habe ich für dieses Knotenprojekt darüber nachgedacht, alle logischen Komponenten wie zuvor intern als Module / Klassen zu gruppieren, so dass sie sich alle gegenseitig referenzieren, sie aber über ein externes Modul verfügbar machen was würde die zugrunde liegenden Klassen usw. offen legen.
Auf diese Weise wäre die Syntax sehr ähnlich bei Knoten, die Mechanismen benötigen, wie:
%Vor%statt
%Vor%Und ich stelle mir vor, dass die Syntax etwa so aussehen würde:
%Vor%Gibt es irgendwelche Best Practices für diese Art von Dingen oder für andere, die etwas Ähnliches getan haben, oder halten sich alle einfach an interne Module für komplexe Dinge?
Ich bin mir nicht sicher, ob das eine schlechte Übung ist oder nicht, aber hier habe ich mein Problem gelöst.
Zuerst eine kurze Zusammenfassung des Problems:
Ich habe mehrere Dateien, die alle logisch unter einem Namespace gruppiert sind, zum Beispiel Framework , dann sind alle darunter liegenden Dateien Framework.* , zB Framework.Database oder Framework.UnitOfWork . Dann werden diese alle über tsc --out framework.js ... kompiliert, so dass ich alles in eine framework.js Datei ausgegeben bekomme.
Nun, das obige klingt gut, aber es erlaubt Ihnen nicht, Module zu exportieren, wenn Sie --out verwenden, da es mehrere Dateien umfasst. Damit der Knoten funktioniert, muss ich die Module irgendwie exportieren, also habe ich im Grunde eine zusätzliche Typoskriptdatei angehängt was macht das für mich in der Zusammenstellung manuell:
%Vor% Wenn dies also die letzte Datei ist, die der tsc -Kompilierung hinzugefügt wurde, erhalten Sie etwas wie:
Damit werden die internen Module ordnungsgemäß exportiert und die Export-Deklaration wird jetzt wegen der Datei exporteur.ts enthalten, die jetzt enthalten ist.
Ich bin also nicht sicher, ob das eine schlechte Praxis ist, aber das erlaubt mir, das Beste aus beiden Welten zu haben, ein wiederverwendbares Modul, das mit Namespaces ausgelegt ist und über eine sinnvolle Dateistruktur verteilt ist, und ein kompiliertes einzelnes Modul die entweder durch Referenzen oder durch Nodejs enthalten sein können.
So würde die Verwendung aussehen:
%Vor%Es gibt einige Ideen, die helfen, einige dieser Probleme zu beheben.
Wenn Sie viele Referenzen haben, können Sie eine Referenzdatei verwenden, um sie zu verwalten. Zum Beispiel:
references.ts
%Vor%Alle anderen Dateien ...
%Vor%Sie haben jetzt eine zentrale Liste Ihrer Referenzen, die viel einfacher ist als die Erstellung von Referenzlisten am Anfang jeder Datei.
In Ihrem speziellen Fall wäre ich eher geneigt, import -Anweisungen zu verwenden und NodeJS zu veranlassen, Module für mich zu laden - und ich würde Module mit dem Dateisystem gruppieren.
Tags und Links node.js typescript amd