Fable: Bringen Sie die Unterstützung für Quellkarten zurück

Wird Fable 3 nicht mehr über das Paket fable-compiler (wird zusammen mit fable-loader )? 😱 Ich verstehe, dass die reine Fable-App eine bessere Benutzererfahrung bietet als Fable-Splitter, um node.js-Apps zu erstellen, aber das Entfernen der npm-Distribution wäre überall eine große Veränderung und ehrlich gesagt ein bisschen mühsam, damit zu arbeiten: Vorlagen, Bibliotheken und Projekte. Es ist einfach so viel einfacher zu sagen: npm upgrade fable-compiler und es wird einsatzbereit sein (hoffentlich ohne Breaking Changes)

Da das Versions-Pinning lokaler Tools behoben wurde, ist es wahrscheinlich der richtige Weg, Fable 3 als Dotnet-Tool zu verteilen, wie es alle anderen F#-Tools tun (Paket, Fake, Fantomas, Femto, Snowflaqe). Fable-Compiler als parallele Distribution zu belassen, wird für die Benutzer wahrscheinlich verwirrender sein, als einen klaren Schnitt zu haben.

Ich würde es vorziehen, wenn sich die Leute daran gewöhnt hätten, Fable als Dotnet-Tool zu bezeichnen 😸 Aber... Ich verstehe, dass das Aktualisieren aller Tutorials, Projekte und Vorlagen mühsam ist (wie in der Vergangenheit). Wir könnten also in Erwägung ziehen, eine neue Hauptversion des Fable-Loaders zu veröffentlichen, die nur das Fable-Dotnet-Tool aufruft. Die Schritte zum Upgrade (wenn stabile Versionen veröffentlicht werden) wären dann nur:

dotnet tool install fable
npm upgrade fable-loader

Wahrscheinlich wird auch *.fs.js zu .gitignore hinzugefügt. fable-compiler kann deinstalliert werden oder nicht, es wird nur nicht aufgerufen. Wie würde das aussehen? Und würde sich jemand freiwillig melden, um den neuen Fable-Loader zu warten? 😉

Fable-Compiler als parallele Distribution zu belassen, wird für die Benutzer wahrscheinlich verwirrender sein, als einen klaren Schnitt zu haben.

Es ist wirklich wichtig, die Abwärtskompatibilität mit den geringsten Änderungen aufrechtzuerhalten und würde viele Leute glücklich machen. Im Moment klingt es aufgrund der eingeführten Indirektionsebene eher nach einem Downgrade (Fable wurde zuerst aufgerufen, dann Webpack) und Webpack erwartet, dass Dateien erst existieren, nachdem Fable sie kompiliert hat, während es im Moment völlig _unsichtbar_ ist und sehr ähnlich aussieht wie TypeScript in bestehende Projekte integriert wird.

Ich mag das CLI-Tool, um das Erstellen und Ausführen von node.js-Anwendungen zu vereinfachen, anstatt fable-splitter zu verwenden

Da das Versions-Pinning lokaler Tools behoben wurde, ist die Verteilung von Fable 3 als Dotnet-Tool wahrscheinlich der richtige Weg

Vielleicht ist es eine Idee, eine Umfrage (z. B. auf Twitter) durchzuführen, um bestehende Benutzer zu fragen, was sie bevorzugen würden?

Verschieben der Diskussion auf #2195, da es sich bei diesem Thema um die Quellzuordnungen handelt und es für Mitwirkende verwirrend sein kann.

Ohne Quellzuordnungen gibt es keine Möglichkeit, das schrittweise Debuggen in VSCode über launch.json , ist das richtig?

Ich vermute, die meisten Front-End-Benutzer werden es sowieso vorziehen, einen zeitreisenden Debugger zu verwenden.

Sie können den VSCode-Debugger weiterhin verwenden, Breakpoints können jedoch nur in den generierten JS-Dateien erreicht werden. Ich habe die Quellzuordnungen sowohl in VSCode als auch in Chrome häufig verwendet (obwohl es manchmal durch Namensmangel schwierig war, Werte zu identifizieren, was wir in Nagareyama verbessern möchten), aber ich weiß nicht, ob viele andere Benutzer dies getan haben.

Ich habe noch keinen Code dazu gestartet, aber ich behalte das im Auge. Meine erste Neigung ist, eine direkte Portierung von Mozilla/Source-Map durchzuführen, vorausgesetzt, dies ist genau das, was benötigt wird, aber dann frage ich mich, ob wir besser C# oder F# für den Port verwenden, ich würde es vorziehen schreibe es selbst in F#, aber die Wahl von C# hat einige Vorteile. In beiden Fällen würde die Portierung der Bibliothek eine native .NET-Implementierung für die Arbeit mit Quellzuordnungen im Allgemeinen bereitstellen, was für das .NET-Ökosystem nützlich sein kann. Im Moment habe ich das Projekt mit der Absicht

Eine andere Option, die mir vielleicht gerade eingefallen ist, wäre, die WebAssembly-Unterstützung für die Mozilla/Source-Map- Bibliothek zu verwenden, um in WebAssembly zu kompilieren und dann das WASM mit Wasmtime in eine .NET-Bibliothek einzubetten . Ich bin mit dieser Option nicht so vertraut, aber wenn sie funktioniert und vernünftig funktioniert, ist es möglicherweise eine einfachere Möglichkeit, die Implementierung mit der ursprünglichen Quellkartenbibliothek in Javascript synchron zu halten.

Eine andere Option, die mir vielleicht gerade eingefallen ist, wäre, die WebAssembly-Unterstützung für die Mozilla/Source-Map- Bibliothek zu verwenden, um in WebAssembly zu kompilieren und dann das WASM mit Wasmtime in eine .NET-Bibliothek einzubetten . Ich bin mit dieser Option nicht so vertraut, aber wenn sie funktioniert und vernünftig funktioniert, ist es möglicherweise eine einfachere Möglichkeit, die Implementierung mit der ursprünglichen Quellkartenbibliothek in Javascript synchron zu halten.

Klingt fast so, als ob wir einen Java-Script to F# Transpiler brauchen...

Im Ernst, eine F#-Quellkartenbibliothek wäre eine gute Idee.

https://github.com/delneg/source-map-sharp
Habe mit der Übersetzung von https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js begonnen
dort, überhaupt nicht der beste Code, aber ich habe versucht, eine direkte Übersetzung zu machen

Das ist großartig @delneg , vielen Dank! Ich denke, eine direkte Übersetzung funktioniert am besten, auch wenn sie nicht F#-idiomatisch ist, falls wir später Updates der Originalbibliothek synchronisieren müssen :+1:

Ich habe einige Arbeit geleistet (hier https://github.com/delneg/source-map-sharp), aber ich brauche möglicherweise Hilfe bei den "util.js" -Funktionen wie util.join , util.relative die in source-map-generator.js

Ich bin mir fast sicher, dass wir util.getArg wegen der F#-Typsicherheit nicht brauchen werden, und ich bin mir fast sicher, dass wir util.toSetString nicht brauchen werden, weil es ein Hack ist, um '__proto__'-bezogene Fehler zu vermeiden.

Bitte sagen Sie mir auch, ob wir das als CLI verwenden oder ... ?

Danke @delneg! Ich werde mir das Wochenende anschauen und versuchen, diese Funktionen zu veröffentlichen :+1: Ja, die Bibliothek wird von Fable.Cli verwendet. Wenn Sie es als unabhängige Bibliothek veröffentlichen, können wir nur auf Ihr Nuget-Paket verweisen.

Ich habe den größten Teil von SourceMapNode, SourceMapGenerator und eine README.md erstellt, um den aktuellen Fortschritt zu präsentieren.
Sie können auch herausfinden, welche Art von Hilfe benötigt wird.

Laut den Dokumenten hier https://github.com/mozilla/source-map#generating -a-source-map reicht das, was wir jetzt haben, aus, um Quellkarten zu generieren ... (obwohl ich nicht ganz sicher bin, wie Geldautomat)

Das ist fantastisch @delneg! Ich habe es kurz versucht und scheint zu funktionieren :+1: Ich werde jetzt versuchen, das Debuggen zu aktivieren.

Das ist schön, können Sie die nächsten Schritte vorschlagen?
Dh Nuget veröffentlichen oder Tests schreiben oder etwas anderes (vielleicht etwas aus der README im Repo)
(PS, obwohl ich noch nie Nuget-Publishing gemacht habe und wahrscheinlich mit einem Fable-Konto erfolgen sollte)
PPS kein Wunder, dass es auf Anhieb funktioniert hat, daran habe ich mich bei der Verwendung von F# ziemlich gewöhnt

Die nächsten Schritte sollten darin bestehen, zu testen, dass Sourcemaps tatsächlich zum Debuggen funktionieren und die zusätzliche Arbeit in Fable erledigen (Hinzufügen der Option --sourceMap , Speichern in einer Datei`. Ich kann dies auf meiner Seite tun. Ich schicke Ihnen auch eine PR um die API ein wenig aufzupolieren (wie die Verwendung optionaler Argumente anstelle von expliziten Optionen).

Im Moment haben wir kein Fable Nuget-Konto, wir veröffentlichen die Pakete mit unserem persönlichen Konto und normalerweise 2-3 Besitzern für alle Fälle. Wenn Sie auf nuget.org ein Konto erstellen und ein Token generieren, können Sie die Veröffentlichung ganz einfach automatisieren . Ich kann das Skript dafür PR. Sie können mich auch als Mitbearbeiter des Pakets hinzufügen, wenn Sie möchten.

Ok, ich schaue mir die Nuget-Publishing-Sachen an, wenn ich Zeit habe
Außerdem habe ich dich als Mitbearbeiter zum Repo hinzugefügt
Wenn es mir möglich ist, werde ich auch versuchen, die API ein wenig zu polieren und einige Tests für SourceGenerator hinzuzufügen

Ich habe begonnen, weitere Tests für SourceMapGenerator hinzuzufügen, sie haben einige Fehler aufgedeckt, die sich versteckten.
Einige sind jetzt behoben, aber bevor es so aussieht, müssen alle behoben werden - sonst funktionieren die Zuordnungen in einigen Fällen möglicherweise nicht
Es ist also noch ein bisschen zu früh, Nuget atm zu veröffentlichen
Wenn jemand helfen möchte - werfen Sie einen Blick auf fehlgeschlagene Tests ( dotnet test )

https://www.nuget.org/packages/source-map-sharp/
Ich habe das Nuget-Paket veröffentlicht, Tests für die SourceMapGenerator-bezogene tatsächliche Mapping-Generierung (SerializeMapping-Funktion) wurden durchgeführt und die Fehler wurden behoben, sodass es ordnungsgemäß funktionieren sollte.
Ich werde mit SourceNode & anderen Sachen weitermachen, und es wäre toll, wenn jemand1 mit util.relative / util.join helfen könnte

Das ist großartig @delneg! Vielen Dank dafür! Ich mache mich nach den Feiertagen langsam wieder an die Arbeit, also werde ich versuchen, eine Fable 3.1-Beta-Version mit Source Map-Unterstützung mit Ihrem Paket zu pushen, wenn möglich :+1:

Ich denke, Fable selbst benötigt keinen SourceNode, aber wenn Sie es der Vollständigkeit halber vorziehen, kann es anderen Benutzern der Bibliothek helfen. Über util.relative/join werde ich auch versuchen, eine PR an Ihr Projekt zu senden, aber da dies auf .NET läuft, denke ich, dass Sie in der Lage sein sollten, System.IO.Path.GetRelativePath und System.IO.Path.Combine : https://docs.microsoft.com/en-us/dotnet/api/system.io.path?view=net-5.0

Leider ist GetRelativePath für netstandard2.0 nicht verfügbar (siehe https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getrelativepath?view=net-5.0#applies -zu)
Die Lösung kann darin bestehen, auf netstandard2.1 zu stoßen (ich weiß jedoch nicht, ob es gut ist).
Bezüglich util.join - nachdem ich alle Vorkommnisse durchgesehen habe, glaube ich, dass es nur in consumer -bezogenen Fällen verwendet wird (was ich nicht tun werde), also ist es im Moment eigentlich nicht so nötig.

PS In Bezug auf den SourceNode usw. - ich denke, wenn wir eine .net-Portierung von Sourcemap machen, lasst uns alles richtig implementieren, was es gibt, auch wenn es jetzt nicht verwendet wird, kann es in ein oder zwei Jahren benötigt werden

.Net Standard 2.1 würde Mono-bezogene Dinge im Staub lassen (zB Xamarin-Dinge). Aber für den Fable-Anwendungsfall ist das wahrscheinlich in Ordnung, da es sich um eine reine Entwicklungsabhängigkeit handelt und das Framework zur Laufzeit sowieso nicht wirklich etwas bedeutet.

Wenn die Bibliothek also nur in Fable verwendet wird, ist 2.1 in Ordnung, aber wenn Sie maximale Kompatibilität mit anderen .Net-Zeugs wünschen, ist 2.0 dafür idealer.

FWIW, jemand hat eine einfache Implementierung davon auf StackOverflow bereitgestellt: https://stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

.Net Standard 2.1 würde Mono-bezogene Dinge im Staub lassen (zB Xamarin-Dinge). Aber für den Fable-Anwendungsfall ist das wahrscheinlich in Ordnung, da es sich um eine reine Entwicklungsabhängigkeit handelt und das Framework zur Laufzeit sowieso nicht wirklich etwas bedeutet.

Wenn die Bibliothek also nur in Fable verwendet wird, ist 2.1 in Ordnung, aber wenn Sie maximale Kompatibilität mit anderen .Net-Zeugs wünschen, ist 2.0 dafür idealer.

FWIW, jemand hat eine einfache Implementierung davon auf StackOverflow bereitgestellt:

Ich denke, ich werde es jetzt auf 2.1 erhöhen und eine Notiz in README für potenzielle netstandard2.0-Benutzer hinterlassen.
Wenn jemand es benötigt, um unter 2.0 zu funktionieren, haben wir eine Fallback-Lösung von Stackoverflow.

Edit: 1.0.1 hochgeladen https://www.nuget.org/packages/source-map-sharp/1.0.1 mit netstandard2.1

Eine andere Möglichkeit wäre, die Dinge, die auf GetRelativePath angewiesen sind, über Multitargeting bedingt auszuschließen (mit #if), sodass alles andere auf .Net-Standard 2.0 verfügbar wäre.

Eine andere Möglichkeit wäre, die Dinge, die auf GetRelativePath angewiesen sind, über Multitargeting bedingt auszuschließen (mit #if), sodass alles andere auf .Net-Standard 2.0 verfügbar wäre.

Scheint eine Überkomplikation für das Problem einer einfachen relativen URL zu sein (nur ATM, die GetRelativePath erfordert)

Fable als Dotnet-Tool ist netcoreapp3.1, also ist es in Ordnung, netstandard2.1 als Ziel zu verwenden, nur müssen Sie möglicherweise den Pfad normalisieren, wenn er in Windows ausgeführt wird, wie Path.GetRelativePath(path, pathTo).Replace('\\', '/') .

Wenn Sie möchten, dass die Bibliothek für maximale Kompatibilität auf netstandard2.0 abzielt, wie https://github.com/fable-compiler/Fable/blob/ba509a94a50522794d3e60f27dd826bb5602eca1/src/Fable.Transforms/Global/Prelude.fs#L508 -L555

Auch Path.GetRelativePath fügt nicht immer einen Punkt vor dem relativen Pfad hinzu:

> Path.GetRelativePath("/foo/bar", "/foo/bar/hoho/mir");;
val it : string = "hoho\mir"

Der Punkt wird wahrscheinlich für Sourcemaps-URLs benötigt, daher müssen Sie möglicherweise auch etwas wie in den Zeilen 545-548 des obigen Auszugs tun, wenn Sie den Pfad normalisieren.

Ich werde mir das obige Zeug ansehen und Tests von JS anpassen (es gibt eine ganze Menge in test-util.js), wahrscheinlich werde ich unsere eigene Implementierung verwenden.
Außerdem bleiben noch ein paar Fragen:
1) Vielleicht sollten wir die Diskussion auf Probleme mit dem Quell-Map-scharfen Repository migrieren?
2) Planen wir, irgendeine Art von WASM-Kompilierung für dieses Projekt zu verwenden (gibt es einen Grund dafür, weil ich den Grund der WASM-Nutzung im ursprünglichen Quellkarten-Repository nicht kenne)?
3) Gibt es noch etwas, das Fable benötigt, um source-map-sharp zu verwenden, wenn überhaupt (einschließlich Dokumente, Tests, zusätzliche APIs usw.)

Edit: OK, das war einfach, habe bereits den benutzerdefinierten Util.getRelativePath hinzugefügt, Tests hinzugefügt und nach geringfügigen Änderungen wurden sie grün.
Sollten wir dann zu netstandard2.0 zurückkehren und/oder 1.0.2 Nuget veröffentlichen?

Super @delneg! 👏 🚀 👏

1. Ja, es ist sinnvoll, die Diskussion in das source-map-sharp-Repository zu verschieben :+1: Bitte erwähnen Sie mich, wenn Sie meinen Beitrag benötigen, damit ich die Benachrichtigung erhalte.
2. Ich habe die WASM-Nutzung in der ursprünglichen Quellzuordnung nicht überprüft, aber ich gehe davon aus, dass sie sie in Umgebungen verwenden, die WASM unterstützen, um numerische Berechnungen zu beschleunigen. Ich glaube nicht, dass wir uns beim .NET-Port darum kümmern müssen.
3. Es sollte in Ordnung sein, ich hatte in diesen Tagen nur nicht viel Zeit, aber ich werde versuchen, bald eine 3.1-Beta-Version mit Source Maps zu veröffentlichen 💪 Sie können 1.0.2 veröffentlichen, also verwenden wir dies in der Beta.

Fable 3.1 Beta wird dank der fantastischen Arbeit von @delneg mit https://twitter.com/FableCompiler/status/1347421291502997504

Fantastisch - von einem Fable-Benutzer: vielen Dank für dieses @delneg !

Erstaunlich Erstaunlich Erstaunlich!

Super @delneg! 👏 🚀 👏

1. Yes it makes sense to move discussion to source-map-sharp repository 👍 Please mention me when you need my input so I get the notification.

2. Didn't check WASM usage in original source-map, but I assume they use it in environments supporting WASM to speed up numeric calculations. I don't think we need to worry about it in the .NET port.

3. It should be fine, I just didn't have much time these days, but I'll try to publish a 3.1 beta release soon with source maps 💪 You can go ahead and publish 1.0.2 so we use this in the beta.

Danke für deine Unterstützung.
Ich werde mein Bestes geben, um Source-Map-scharf in Zukunft beizubehalten, und ich bin froh, dass es jetzt funktioniert.
1) Ich schreibe dann in die Ausgaben des Repos, und wenn jemand Fragen usw. hat - bitte eröffne ein Problem in source-map-sharp
2) Ja, ich nehme an, sie haben WASM verwendet, um die Leistung zu verbessern.
Ich habe die WASM-Version von source-map-sharp ausprobiert und zum Laufen gebracht, aber der Zustand der WASM-Kompilierung in .net scheint schrecklich und sehr schwer zu verwenden (einige Arbeit wird im Uno.Platform.Bootstrap-Projekt erledigt, aber wenn man es sich ansieht?) Quellcode hat mich sehr enttäuscht)
Soweit source-map-sharp eine .NET-Anwendung ist, können wir uns, wenn wir jemals mehr Leistung benötigen, immer nach Span . umsehenund andere .NET-Sachen, um es schneller zu machen
3) Ich habe 1.0.2 veröffentlicht und ich habe gesehen, dass Sie es bereits verwendet haben, also das war's.
Ich werde versuchen, in Zukunft weiterhin Nugets zu veröffentlichen, wenn wir Fehler usw. finden (und versuchen, die API nicht zu ändern)

Für alle, die die Quellzuordnungen nach Anwendung der Anweisungen von .fs.js -Dateien) zu bereinigen und Ihren Build erneut auszuführen. Ich habe eine Weile gebraucht, um das herauszufinden, da ein einfacher Wiederaufbau ohne Reinigung nicht funktionierte.

Ansonsten vielen Dank an alle Beteiligten, die dieses tolle Feature zurückgebracht haben 👍

Gute Arbeit! Ich bin heute zurückgekommen, um zu sehen, ob ich dieses Projekt aufnehmen könnte und zu meiner Freude ist es bereits abgeschlossen. Ich habe das Repo archiviert, mit dem Gerüstbau begonnen hatte , und habe vorerst auf das https://github.com/delneg/source-map-sharp-Repo verwiesen. Wieder tolle Arbeit!