Fable: Fable-Loader zurückbringen?

Wie sieht Ihr Arbeitsablauf aus, wenn wir keinen Lader haben? Wird Fable den F#-Code einfach in ein Ausgabeverzeichnis kompilieren und dann Webpack oder ein anderer Bundler von dort aus übernehmen?

Ich habe die Fortschritte bei Nagareyama in letzter Zeit nicht beobachtet, also verzeiht mir, wenn das schon irgendwo geklärt wurde.

Es wäre sicherlich sehr schön, Fable einfach einzurichten, ohne eine Vorlage verwenden zu müssen.

Hallo @inosik! Das Ziel von Nagareyama ist es, Fable einfacher zu machen, indem die .NET/JS-Mischung im Compiler selbst entfernt wird. Fable wird also zu einem "reinen" Dotnet-Tool, das über Nuget vertrieben wird und dessen einzige Aufgabe darin besteht, JS-Dateien auszuspucken (um komplexe Interaktionen mit JS-Tools zu vermeiden). Um ein F#-Projekt zu kompilieren (da es Fable-kompatibel ist), müssen Sie nur Folgendes tun:

dotnet tool install fable
dotnet fable src/Client

Sie können ein Ausgabeverzeichnis festlegen, wenn Sie möchten, aber standardmäßig legt Fable die .js-Dateien neben die .fs-Dateien.

Dann können Benutzer mit den JS-Dateien tun, was sie wollen. Im üblichen Fall, sie mit webpack zu bündeln, müssen sie nur die zuletzt generierte .js-Datei als Eintrag in der webpack.config setzen (keine zusätzlichen npm-Abhängigkeiten wie fable-loader erforderlich). Der Einfachheit halber kann Fable nach der Kompilierung einen Befehl ausführen, wie in dotnet fable src/Client --run webpack oder dotnet fable watch src/Client --run webpack-dev-server

Der neue Ansatz gefällt mir.
Würde diese Änderung zukünftige Geschwindigkeitsoptimierungen wie HMR beeinträchtigen? Gibt es keine Art von Parallelitätsverlust?

Ich denke nicht, dass es HMR beeinflussen sollte, aber bitte melden Sie sich, wenn Sie etwas sehen. Es stimmt, dass bei Verwendung von --run Webpack nicht startet, bis die Kompilierung abgeschlossen ist, dafür gibt es die Option --runFast , die den Unterprozess vor der F#/Fable-Kompilierung ausführt. Wenn also die JS-Dateien bereits existieren (normalerweise von einer vorherigen Kompilierung), kann Webpack parallel arbeiten und die Zeit von 0 bis der Server läuft, reduziert sich im Wesentlichen auf die Bündelungszeit. Und wenn Fable parallel fertig ist, sind die Uhren-Compilations wie gewohnt sehr schnell.

Ich versuche derzeit, eine App mit einem Back-End mit Azure Functions (die auf Azure Static Websites gehostet werden soll) zusammenzustellen, und was ich tue, ist das Einrichten von Weiterleitungen für die lokale Entwicklungsumgebung bei der Verwendung von Paketen, wie in der minimalen Fable gezeigt3 Beispiel.

Persönlich würde ich mich sehr freuen, Webpack loszuwerden und den Stack zu vereinfachen, aber diese Anleitung zum Einrichten von so etwas wie einer SAFE-Stack-App wäre sehr hilfreich. Wenn das ohne fable-loader möglich wäre, dann sollte es in Ordnung sein, ihn nicht zu haben.

Für Tipps wäre ich dankbar :-)

@uxsoft Haben Sie die Seite _API Proxy_ bereits in den Parcels-Dokumenten gesehen? Aber es sieht so aus, als wäre es ein bevorstehendes Feature von Parcel v2, das anscheinend noch nicht veröffentlicht wurde. Es sieht so aus, als hätte Parcel keinen integrierten Proxy in v1.

Ich habe vor einem Jahr einen Blog-Beitrag gefunden , in dem der Autor beschreibt, wie man eine Entwicklungsumgebung mit Parcel und einem Express-Server, der als Proxy fungiert, einrichtet. Vielleicht hilft das.

@uxsoft Um Ihr Projekt zu aktualisieren, ohne Webpack zu berühren, können Sie diesem Beispiel folgen: https://github.com/MangelMaxime/fulma-demo/pull/43

Nun, in diesem Fall sollte kein Fable-Loader erforderlich sein, wenn wir sowieso an den Webpack-Entwicklerserver weiterleiten können, oder?

Ja, das ist richtig. Der einzige Zweck des "neuen" Fable-Loaders besteht darin, Benutzern das Upgrade auf Fable 3 zu ermöglichen, ohne ihre Webpack-Konfiguration oder ihr Build-Skript zu berühren, aber ich persönlich würde es vorziehen, wenn sich die Leute an die neue Art gewöhnen, da sie mit anderen F# ausgerichtet ist Tools und um zu vermeiden, dass Sie zwei Arten der Verwendung von Fable pflegen/dokumentieren müssen.

Auf jeden Fall scheinen die Benutzer mit der Änderung zufrieden zu sein, daher werde ich dieses Thema vorerst schließen, um Verwirrung zu vermeiden. Bei Bedarf können wir später noch einmal vorbeischauen.

Ein neuer Fable-Loader könnte nützlich sein, falls einige JS-Tools die Webpack-Konfiguration als Eingabe-/Einstiegspunkt verwenden. Zum Beispiel - Cloudflare-Worker: https://developers.cloudflare.com/workers/cli-wrangler/webpack

@Krzysztof-Cieslak Die Einstellung von fable-loader bedeutet nicht, dass Sie Fable nicht mehr mit Webpack verwenden können, es bedeutet nur, dass die Verwendung in Webpack einfacher wird, weil es einfach so wird:

• dotnet fable löst Fable als Dotnet-CLI-Tool aus
• Fable kompiliert F#-Dateien in JS-Dateien (Module)
• Webpack bündelt sie

Anstatt von:

• fable-loader löst Fable als Einstiegsmodul-Loader aus
• Fable kompiliert F#-Dateien in JSONified Babel AST (relativ langsam)
• babel-loader nimmt JSON babel AST und gibt JS-Code aus
• Webpack bündelt sie

Ich habe das Problem bei @alfonsogarciacaro angesprochen, weil ich dachte, es würde die Migration einfacher machen, wenn wir den fable-loader beibehalten und nur fablec-compiler (das npm-Paket) auf das neueste Fable aktualisieren, aber vielleicht wäre es viel besser, wenn wir alles vereinfachen würden unsere Vorlagen und entfernte diese Lader komplett (funktioniert auch gut mit anderen Bundles wie Paket)

Sicher, es bedeutet "nur", dass ich zusätzliche Schritte in meinen Build-Prozess für etwas einfügen muss, das früher ein einzelner Schritt war.

Ihr Anruf, wenn das ein vernünftiger Kompromiss ist / Achselzucken

Der Build-Schritt ist immer noch nur ein Befehl, außer dass er jetzt keine zusätzlichen Webpack-Loader _erfordert_ und problemlos mit verschiedenen Bundlern verwendet werden kann.

# compile project using Fable
dotnet fable ./src 

# compile project then trigger bundler (production build)
dotnet fable ./src --run webpack

# build in watch mode
dotnet fable watch ./src

# build in watch mode and trigger a bundler after compilation
dotnet fable watch ./src --run webpack-dev-server

Webpack muss lediglich die aus Fable generierte JS-Eintragsdatei ( {lastFile}.fs.js ) als Eintragsdatei für die Bündelung und Verkleinerung kennen. fable-loader und babel-loader werden nicht benötigt.

@alfonsogarciacaro Gibt es ein dotnet fable run , das dotnet run und automatisch node {lastFile}.fs.js auslöst, nachdem die Kompilierung erfolgreich abgeschlossen wurde? Könnte ein interessanter Befehl sein, um Fable zu präsentieren 🤔

Der Build-Schritt ist immer noch nur ein Befehl

Nicht wirklich im Fall von CF Workers Tools - es war früher ein einzelner Aufruf von wrangler dev (was unter der Haube irgendwie Webpack verwendete, die unter der Haube Fabel mit Loader ausführte). Jetzt wird zuerst Fabel kompiliert und dann Wrangler aufgerufen.

Auch hier ist es keine große Sache - ich gebe mehr nur ein Beispiel, wo der alte Workflow besser passte.

Das Vorgängermodell hat mir auch sehr gut gefallen, aber jetzt, wo ich die neuen Sachen ausprobiert habe, schätze ich die Leistungssteigerung der Zusammenstellung sehr, wenn all dieser Overhead entfernt wird

Funktioniert so etwas wie dotnet fable dev --run wrangler dev ? Theoretisch könnten wir einen neuen Fable-Loader haben, der nur dotnet fable aufruft, aber es kann Probleme beim Starten/Stoppen der Prozesse, des Watchers usw. geben. Also würde ich es vorziehen, es zu vermeiden.

dotnet fable watch src --outDir tmp --run wrangler dev scheint das zu tun, was ich will (dh sowohl Fable als auch Wrangler im Watch-Modus).

Es gibt ein Problem damit, dass der Wrangler-Prozess nicht beendet wird, nachdem ich den Dotnet-Fabelprozess beendet habe, aber es ist kein großes Problem.

Cool! Hmm, es gab einige Berichte über ein ähnliches Problem, aber ich dachte, sie wären behoben. Kannst du dir bitte #2212 anschauen? Verwenden Sie Windows? Ich hänge nur die Beendigungsereignisse in Windows an, weil ich dieses Problem in macOS nicht gesehen habe, aber wir müssen das möglicherweise auch tun: https://github.com/fable-compiler/Fable/blob/111a0b2175bf605594817f849109fedef04eb6f3/src/ Fable.Cli/Util.fs#L127 -L136