In den letzten drei oder vier Jahren, als ich in PHP programmierte, habe ich composer , um Anwendungsabhängigkeiten zu verwalten. Jetzt müssen Sie zu nodejs wechseln und eine vertraute Entwicklungsumgebung konfigurieren. Glücklicherweise verwende ich die PhpStorm-IDE, mit der Sie sowohl mit PHP als auch mit JS arbeiten können. Ein Merkmal der Projekte, an denen ich teilnehme, ist die Multimodularität. Die Funktionalität wird auf die Module aufgeteilt, die nicht so sehr zur Wiederverwendung bestimmt sind, als dass die endgültige Komplexität der Anwendung aufgrund der Zerlegung in lose gekoppelte Komponenten verringert wird. Im Allgemeinen ist es für diese Projekte normal, wenn im Rahmen der Lösung eines Problems Änderungen an mehreren Modulen vorgenommen und an mehrere Repositorys übergeben werden.
Beim Einrichten eines nodejs Projekts bin ich auf einige Funktionen nodejs , die die Entwicklung nodejs Module erschweren. Diese Veröffentlichung entstand im Prozess des Versuchs, mit diesen Merkmalen umzugehen. Im Rahmen der Kürzung befasst sich PHP mit der Bereitstellung eines nodejs Projekts.
Demo-Projektstruktur
Das Projekt besteht aus 3 Modulen:
- Anwendung : Kopfmodul, das Abhängigkeiten verbindet;
- Funktionsmodul : enthält Funktionen, die vom Kopfmodul aufgerufen werden;
- Basismodul : enthält Funktionen, die von einem Funktionsbaustein aufgerufen werden;
Der Code für jedes Modul befindet sich auf github:
Die package.json für die jeweiligen Abhängigkeitsmanager ( composer.json und package.json ) befinden sich in jedem Modul, d. H. Jedes Modul kann sowohl als PHP-Modul als auch als JS-Modul erweitert werden. PHP-Code und JS-Code in den Modulen werden einfach nebeneinander platziert, ohne sich zu überschneiden.
Ausführen der Anwendung zur Ausführung:
$ php index.php $ nodejs index.js
Das Ergebnis der Arbeit in beiden Fällen:
This is application. This is func module. This is base module.
Ziele
Ein Projekt in einer Arbeitsumgebung sollte Folgendes ermöglichen:
- Verfolgen Sie die IDE-Änderungen in jedem an der Entwicklung beteiligten Modul.
- Übernehmen Sie mit der IDE Änderungen in einer einzigen Aktion an verschiedene Repositorys.
- Verwenden Sie den Debugger, um die Ausführung des Codes der Module zu verfolgen.
Bereitstellung durch composer
Hier ist alles bekannt. Geben Sie im Bereitstellungsdeskriptor ( composer.json ) der Anwendung die Adressen der Repositorys mit den Modulen an und schreiben Sie die Hauptzweige der Module als Abhängigkeiten mit der gewünschten Version vor:
{ "require": { "flancer64/habr-cvsn-mod-base": "dev-master as 0.1.0", "flancer64/habr-cvsn-mod-func": "dev-master as 0.1.0" }, "repositories": [ { "type": "vcs", "url": "https://github.com/flancer64/habr-cvsn-mod-base" }, { "type": "vcs", "url": "https://github.com/flancer64/habr-cvsn-mod-func" } ] }
Nach dem Ausführen des Befehls:
$ composer install
./vendor mit Modulen werden im Verzeichnis ./vendor , das wiederum ./vendor Verzeichnisse enthält:
./vendor/
./flancer64/
./habr-cvsn-mod-base/
./habr-cvsn-mod-base/
Das heißt, composer die Abhängigkeiten sofort in einer für die Entwicklung geeigneten Form bereit (Versionskontrolle). Es bleibt nur die Konfiguration der PhpStorm-IDE (abhängige Module unter Versionskontrolle stellen):
und Sie können Änderungen in allen entwickelten Modulen verfolgen:
und alle Änderungen gleichzeitig an lokalen Repositorys festschreiben:
und auf Fernbedienung drücken:
Debugging ist auch kein Problem. Wir können Haltepunkte in jeder Zeile des Basismodulcodes festlegen. Nach dem Starten der Anwendung unter dem Debugger tritt die Unterbrechung bei Bedarf auf:
Im Allgemeinen die übliche Umgebung, bequem wie Hausschuhe.
Normale Bereitstellung durch npm
Im Gegensatz zu composer npm nicht davon aus, dass im Projekt Module aus dem Verzeichnis node_modules möglicherweise der Versionskontrolle node_modules . Wir können im Deployment Descriptor package.json angeben, dass das Modul aus einem externen Repository (z. B. aus Githib) geladen werden soll:
{ "dependencies": { "habr-cvsn-mod-base": "github:flancer64/habr-cvsn-mod-base", "habr-cvsn-mod-func": "github:flancer64/habr-cvsn-mod-func" } }
Wir haben jedoch nicht die Möglichkeit, dass npm ein lokales Repository für das geladene Modul erstellt (Unterverzeichnis .git ).
Nach dem Ausführen des Befehls:
$ npm install
Abhängigkeiten werden heruntergeladen und lokal installiert, ohne dass die Versionskontrolle verwendet werden kann:
(fehlendes Unterverzeichnis ./.git/ in ./node_modules/habr-cvsn-mod-base/ )
Der Debugger stoppt jedoch problemlos im Basismodul:
Bereitstellung über npm mithilfe der Link-Option
Damit Module von ./node_modules/ unter Versionskontrolle gehalten werden können, empfehlen npm Entwickler die Verwendung der Option ' link '. Kurz gesagt besteht der Kern des Ansatzes darin, dass die Module, die versioniert werden müssen, an eine beliebige Stelle auf der Entwicklerfestplatte geklont werden (z. B. in /home/alex/work/habr/ ) und dann mit /usr/lib/node_modules/ mit dem Befehl:
# npm link
(Ich brauchte Root-Rechte, um auszuführen)
Danach können Sie die Befehle bereits im Projekt verwenden:
$ npm link habr-cvsn-mod-base $ npm link habr-cvsn-mod-func
npm findet die entsprechenden Module in /usr/lib/node_modules/ und schließt die entsprechenden Unterverzeichnisse aus dem Projekt ./node_modules/ für sie:
$ ls -lh ./node_modules/ total 0 lrwxrwxrwx 1 alex alex 57 jūl 2 16:18 habr-cvsn-mod-base -> ../../../../../../usr/lib/node_modules/habr-cvsn-mod-base lrwxrwxrwx 1 alex alex 57 jūl 2 16:18 habr-cvsn-mod-func -> ../../../../../../usr/lib/node_modules/habr-cvsn-mod-func
Die Module in /usr/lib/node_modules/ selbst sind wiederum Links zum ursprünglichen Speicherort der Module:
$ ls -lh /usr/lib/node_modules/ ... lrwxrwxrwx 1 root root 39 jūl 2 16:18 habr-cvsn-mod-base -> /home/alex/work/habr/habr-cvsn-mod-base lrwxrwxrwx 1 root root 39 jūl 2 16:18 habr-cvsn-mod-func -> /home/alex/work/habr/habr-cvsn-mod-func ...
Und an ihrem festen Platz enthält "Registrierung" ein lokales Repository:
$ ls -lha /home/alex/work/habr/habr-cvsn-mod-base ... drwxrwxr-x 8 alex alex 4,0K jūl 2 16:18 .git ...
Auf diese Weise können wir die IDE so konfigurieren, dass Änderungen in den Projektabhängigkeiten gesteuert werden:
Probleme beginnen, wenn Sie versuchen, die Anwendung auszuführen:
$ nodejs index.js internal/modules/cjs/loader.js:670 throw err; ^ Error: Cannot find module 'habr-cvsn-mod-base' at Function.Module._resolveFilename (internal/modules/cjs/loader.js:668:15) at Function.Module._load (internal/modules/cjs/loader.js:591:27) at Module.require (internal/modules/cjs/loader.js:723:19) at require (internal/modules/cjs/helpers.js:14:16) at Object.<anonymous> (/home/alex/work/habr/habr-cvsn-mod-func/src/index.js:3:14) ...
Die Anwendung sieht das verknüpfte Funktionsmodul, aber das Funktionsmodul selbst sieht das verknüpfte Basismodul nicht. Verwenden Sie zum Beenden der Situation den Schlüssel --preserve- nodejs für nodejs :
$ nodejs --preserve-symlinks index.js
Fügen Sie den Schlüssel zum Projektstartbefehl in der IDE hinzu:
Jetzt ist der Start erfolgreich, aber es gibt Probleme beim Debuggen - Haltepunkte in Abhängigkeiten funktionieren nicht. Sie können im Kopfmodul anhalten und die Schritte zu den Abhängigkeitsquellen ausführen, aber der IDE PhpStorm sieht den Haltepunkt selbst zur Laufzeit nicht, obwohl Folgendes angezeigt wird:
IDE-Entwickler sagen, dass es funktionieren sollte, aber es funktioniert nicht (der Cache wurde geleert, die IDE neu gestartet).
Im Allgemeinen bestand der Zweck dieser Veröffentlichung darin, js-Kollegen zu befragen, wie sie in einer ähnlichen Situation herauskommen. Beim Schreiben des Artikels ergab sich jedoch eine andere Kombination für die Entwicklung des Projekts:
Platzierung von Quellcodes in internen Verzeichnissen von npm-project
Es stellte sich heraus, dass js-Skripte ohne den --preserve-symlinks werden, wenn Sie zum Verknüpfen Klone von Modulen aus github verwenden, die von composer im Unterverzeichnis ./vendor/ erstellt wurden, anstatt an Verzeichnisse außerhalb des Projekts gebunden zu sein. Noch wichtiger für mich ist, dass die PhpStorm-IDE Haltepunkte in Modulen erkennt. Weil Es macht keinen Sinn, composer nur zum Klonen von Projektmodulen zu verwenden. Ich habe das übliche git und den Quellcode der Module in das Unterverzeichnis ./own_modules . Dann wiederholte er die Manipulationen aus dem vorherigen Absatz:
- verknüpfte die Module im Unterverzeichnis
./own_modules/... mit der Systembibliothek /usr/lib/node_modules/ ; - verbundene Module in der Systembibliothek mit dem Projekt;
- Konfigurierte die PhpStorm-IDE für die Arbeit mit lokalen Repositorys im Unterverzeichnis
./own_modules/ .
Ich weiß nicht, was der Grund ist, aber wenn sich die Quellen der abhängigen Module innerhalb des Projekts befinden, unterscheidet sich das Endergebnis der Assembly erheblich von dem, wenn sich die Quellen der abhängigen Module in einem Verzeichnis außerhalb des Projekts befinden.
Zusammenfassung
Wenn ich die beiden Ansätze zum Erstellen von Anwendungen mit mehreren Modulen (PHP mit composer und JS mit npm ) vergleiche, kann ich schließen, dass composer entwicklerfreundlicher ist als npm . Es ist möglich, dass die composer Entwickler (erste Veröffentlichung im Jahr 2012) die Erfahrungen der npm Entwickler (erste Veröffentlichung im Jahr 2010) berücksichtigt haben. Mit einigem zusätzlichen Aufwand bietet npm auch die Möglichkeit, Anwendungen mit mehreren Modulen unter recht komfortablen Bedingungen zu entwickeln.
Befehlsskripte für die Projektbereitstellung in verschiedenen Modi: