SPFX Entwicklung in Docker

Ich hatte vor kurzem einen Artikel dazu geschrieben, mit dem ich ein SPFX Paket in einem CDN installieren kann.

Heute wollte ich noch einmal darauf eingehen, wie ich aktuell SPFX Webparts entwickle. Mein Anspruch war, das ich mein Hostsystem nicht “voll mülle” mit Entwicklungsumgebungen. Jedoch wollte ich jetzt keine komplette VM erstellen nur um diese Workbench zum laufen zu bekommen. Somit will ich auf meinem Hostsystem nur die Quellen unter Sourcecontrol haben, und die Entwickler Tools separiert installieren, so dass ich das immer wieder neu verwenden kann.

Dazu ergab sich bei mir die Lösung mit Hilfe eines Docker Images.

Docker

Da ich das Rad nicht neu erfinden muss, habe ich mit ein bisschen Suchen herausgefunden das es bereits ein Docker Container existiert. In diesem kommt so gut wie alles für die SPFX Entwicklung mit.

Mit diesem Befehl wird die Maschine gestartet und verwendet das Verzeichnis aus d:\sourcen als ausgangsbasis. Somit habe ich die Quellen immer auf dem Hostsystem, aber die Umgebung virtualisiert”.

Beim erstmaligen ausführen kann es dazu kommen, das noch das Image selbst aus dem Netz geladen werden muss.

Erstellen des ersten Projekts

In dem Docker Container ist der yeoman Gernerator bereits vorhanden, so dass mit dem Befehl:

Mit diesem Generator besteht nurn die Möglichkeit beispielsweise ein Webpart mit dem SharePoint Framework zu erstellen.

Nachdem der Wizard durchgelaufen ist, ruft er die ersten Pakete ab und legt sie in dem node_modules Ordner ab. Bei der Wiederherstellung der Pakete ist gut zu erkennen, das diese nicht im Container abgelegt werden sondern im Zugewiesenen Hostverzeichnis:

Vor der ersten Ausführung

Bevor die Anwendung zum ersten Mal ausgeführt wird, sind noch zwei Schritte zu erledigen.

  1. Erweitern der HOSTS Datei
  2. Anpassen der gulp_connect Bibliothek

Erweitern der HOSTS Datei

Dadurch das dem Container ein Hostname “spfx” zugewiesen wurde, ist es nun soweit diese auch lokal zu verwenden. Da aber das Host-System davon noch nichts weis, muss dies in der HOSTS Datei (c:\Windows\System32\drivers\etc ) durch folgenden Eintrag zugewiesen werden:

 

Anpassung der gulp_connect Bibliothek

Dieser Schritt war bei mir notwendig. Denn ohne diese Anpassung konnte ich die Entwickler Workbench nicht öffnen.

Was ich machen musste war in der Datei ./node_modules/gulp-connect/index.js auf Zeile 106 die Zeile:

mit

ersetzen. Ab jetzt war mein Container startbereit.

Starten der Entwicklungsumgebung

Zum starten der Entwicklungsumgebung reicht es aus den Befehl

auszuführen und auf die Adresse https://spfx/workbench zu navigieren.

Nun besteht die Möglichkeit das Webpart zu bearbeiten. Dieser Server kann immer zu gestartet bleiben, denn eine Änderung an den Quellen erzeugt ein Neuladen des Webparts in Echtzeit mit angepassten Quellen.

Ich finde das ist ein kleine Aufwand aber hat für mich ein hohen Mehrwert bei der Realisierung von Webparts oder aber auch Commands in SharePoint.