Fable: Automatisches Bündeln/Entwicklungsserver?
Bisher hat Fable versucht, eine Brücke zwischen F#- und JS-Ökosystemen zu schlagen. Und als solches versuchte es nicht zu viel zu tun und ließ den Benutzer stattdessen seine JS-Tools zum Bündeln, Debuggen des Frontends usw. auswählen Das Erscheinen von Bibliotheken, die keine npm-Abhängigkeiten erfordern, wie Sutil oder Elmish.Snabbdom (oder sogar React, wenn Sie es von einem CDN verwenden), kann besonders für Neulinge hilfreich sein, wenn Fable die grundlegenden Operationen ausführen (oder zumindest aufrufen) könnte Schreiben Sie das Frontend einer Web-App: Bündelung und Entwicklungsserver. Dafür würden wir neue CLI-Argumente wie --serve und/oder --bundle .
Unseren eigenen Bundler zu schreiben, liegt außer Kontrolle. Zuerst dachte ich, wir könnten einen Bundler in das Fable-Paket einbetten, aber wahrscheinlich ist es einfacher, einfach ein verstecktes .fable-tools -Verzeichnis zu erstellen, dort die benötigten Tools mit npm zu installieren und sie bei Bedarf aufzurufen. Ideal wäre es, sich auf einen Bundler mit guten Standardeinstellungen zu verlassen, der aber bei Bedarf angepasst werden kann. Die Frage ist, welchen Bundler man verwenden soll?
- Webpack: die am weitesten verbreitete und wahrscheinlich bevorzugte Option, wenn der Benutzer Anpassungen vornehmen muss. Standardwerte werden wahrscheinlich nicht ausreichen, aber wir könnten eine automatische webpack.config generieren und den Benutzer bei Bedarf anpassen lassen. Wenn ich mich nicht irre, funktioniert create-react-app so.
- Paket: Dies wäre ein sehr guter Kandidat, da es viele gute Standardeinstellungen hat, aber sie scheinen für immer im v2-Upgrade festzustecken.
- Rollup: Wir haben es wegen seiner Benutzerfreundlichkeit manchmal in Fable verwendet, aber in letzter Zeit finde ich es mangelhaft und schwierig anzupassen, insbesondere den Dev-Server.
- Andere? Ich habe die neuen Bundler wie Snowpack oder wie die jetzt heißen 😅 aus den Augen verloren
Irgendwelche Meinungen? Denken Sie daran, dass dies nur optional ist und die Benutzer weiterhin jeden anderen Bundler auswählen können, wie es jetzt der Fall ist.
alfonsogarciacaro
Alle 3 Kommentare
Ich glaube nicht, dass das eine gute Idee ist. Es wird die Grenze zwischen der F#- und der JavaScript-Welt wieder verschwimmen lassen. Ähnlich wie in Fabel 2, wo es den Leuten schwer fiel zu verstehen, was wofür verantwortlich war.
Fable 3 ist großartig, denn sobald Sie Fable aufgerufen haben, um die JavaScript-Dateien zu generieren, befinden Sie sich direkt in der JavaScript-Welt. So finden Sie alle gewünschten Dokumentationen zu diesem Thema, die von der JavaScript-Community erstellt wurden.
Ich würde weitgehend eine gut gemachte Dokumentation bevorzugen, die erklärt, wie die Arbeit von Fable 3 beginnt und stoppt (Kompilieren von F # in JS), und dann den Leuten von hier erklären, dass Sie das Tool verwenden können, das Sie bevorzugen. Und haben Sie eine einfache Dokumentation, die erklärt, wie es geht, und delegieren Sie die Erklärung dann an die Dokumentation des ausgewählten Tools.
IHMO, Menschen müssen das Ökosystem verstehen, in/mit dem sie arbeiten. Ja, für eine wirklich einfache Präsentation können Sie die Funktionsweise von JavaScript usw. ignorieren. Aber schon bald müssen Sie das große Ganze verstehen, um Ihre Bewerbung schreiben zu können.
Wenn wir in einer ähnlichen Position wären wie Sprachen, die 100 % ihrer Pipeline und ihres Ökosystems wie Elm kontrollieren, würde ich anders denken.
Aus dem gleichen Grund ziehe ich es vor, concurrently zu verwenden, um Fable und den JavaScript-Bundler nebeneinander aufzurufen. Anstatt Fable dazu zu bringen, den JavaScript-Bundler aufzurufen.
Es ist nicht viel, aber es „zeigt“, dass sie ohne Magie Seite an Seite arbeiten. Wenn wir dotnet fable --run XXX ausführen, ist nicht klar, dass der Befehl nur einmal ausgeführt wird, selbst wenn Sie sich im Überwachungsmodus befinden.
IHMO, in all diesen kleinen Details können wir Klarheit/Transparenz darüber erlangen, wie die Dinge funktionieren/funktionieren.
MangelMaxime
am 1. Apr. 2021
Meine persönliche Meinung, wie sie in früheren Diskussionen zu diesem Thema geäußert wurde, ist, dass es sehr sinnvoll ist, die Designziele zu übernehmen und einzuhalten, die auch andere Transpiler wie TypeScript haben, insbesondere den Abschnitt „Nicht-Ziele“ (dh die „we möchte das nicht tun"-Abschnitt), und bei diesem speziellen Thema ist das nächste "Nicht-Ziel" Nummer 4.
ncave
am 1. Apr. 2021
Du hast recht. Das ist wahrscheinlich eines der Dinge, über die ich mich freue und die ich danach bereue 😅 Ok, lass uns das schließen. Jetzt, da die Dinge stabiler werden, können Neulinge die Dinge einfacher machen, indem sie die Vorlagen verbessern :+1:
alfonsogarciacaro
am 2. Apr. 2021
Verwandte Themen
nozzlegear
·
3Kommentare
alfonsogarciacaro
·
3Kommentare
SirUppyPancakes
·
3Kommentare
forki
·
3Kommentare
MangelMaxime
·
3Kommentare
Hilfreichster Kommentar
Du hast recht. Das ist wahrscheinlich eines der Dinge, über die ich mich freue und die ich danach bereue 😅 Ok, lass uns das schließen. Jetzt, da die Dinge stabiler werden, können Neulinge die Dinge einfacher machen, indem sie die Vorlagen verbessern :+1: