2016-04-22 9 views
5

Ich habe vor kurzem mit Suave begonnen; Ich habe ein Projekt mit Yeoman und dem F # -Generator eingerichtet. Um die App auszuführen, erstelle ich eine ausführbare Datei mit Fake und führe sie dann aus. Immer wenn ich eine der App-Dateien, d. H. * .fs-Dateien, ändere, muss ich den Prozess zum Erstellen und Ausführen einer ausführbaren Datei wiederholen.Reload Suave App auf Datei Speichern

Gibt es einen besseren Prozess für die Entwicklung, bei dem die App neu erstellt oder neu geladen/neu gestartet wird?

+0

FsReveal Build-Skript tut dies: https://github.com/fsprojects/FsReveal/blob/master/build.fsx – Foole

Antwort

4

Das Build-Skript für die F# Snippets project tut genau dies.

Die Idee ist, dass Sie Datei haben, die eine Top-Level-WebPart mit dem Namen app definiert. Sie können das Beispiel für F# Snippets here sehen. Die Skriptdatei kann auch andere Dateien laden, sodass Sie Ihre Anwendung beliebig strukturieren können.

Den build.fsxbuild script beginnt dann einen Server, Monitore Systemänderungen für Ihren Quellcode und app.fsx und lädt sie im Hintergrund mit F# Compiler Service Datei und ersetzt den „aktuell geladenen“ Server mit dem von dem neuen app Wert erhielt ein.

Die einzige Einschränkung des aktuellen Buildskripts besteht darin, dass der Speicher nicht korrekt neu erstellt wird (es sollte wahrscheinlich durch erneutes Erstellen von F # Interactive Session im Buildskript behoben werden) und daher nach einer größeren Anzahl von Neuladungen nicht genügend Arbeitsspeicher vorhanden ist. Aber es macht den Workflow noch viel schöner!

+0

Wie ich es verstehe, ist eine Alternative Skriptdateien (.fsx) verwenden. Gibt es einen "Best Practice" -Migrationspfad von einer skriptgesteuerten suave-App zu einer kompilierten? – Ari

+0

Sie können das Projekt so einrichten, dass es in beide Richtungen funktioniert. Siehe https://github.com/fssnippets/fssnip-website zum Beispiel. –

1

Ich verwende einen ähnlichen Ansatz zu Tomas, aber führen Sie den Server in einem untergeordneten Prozess des Buildskripts. Dies führt dazu, dass der Neustart beim Neustart etwas langsamer wird, jedoch keine Speicher oder Ports ausgibt. Dadurch kann ich auch problemlos ein anderes Arbeitsverzeichnis für meine Build-Skripte als für meine App-Skripte (in diesem Fall ./app) verwenden.

Hier ist eine verkürzte Version meines FAKE-Skripts.

#r "packages/FAKE/tools/FakeLib.dll" 
open Fake 

let wait() = System.Console.Read() |> ignore 

let runServer() = 
    fireAndForget (fun startInfo -> 
     startInfo.WorkingDirectory <- "./app" 
     startInfo.FileName <- FSIHelper.fsiPath 
     startInfo.Arguments <- "--define:RELOAD server.fsx") 


Target "Watch" (fun _ -> 
    use watcher = !! "app/*.fsx" |> WatchChanges (fun changes -> 
     tracefn "%A" changes 
     killAllCreatedProcesses() 
     runServer() 
) 
    runServer() 
    wait() 
)