Fable: Fable.Import-Paket erstellen

@alfonsogarciacaro Fable.Core.Extensions.fs ist auch von Fable.Import.JS.Promise abhängig. Wir können entweder die gesamte Fable.Import.JS behalten oder nur den Promise/PromiseLike-Teil davon, was sich wahrscheinlich nicht ändern wird.

Ich denke, das wäre eine gute Idee.

Ich würde mich für drei verschiedene Pakete entscheiden, aber die Benutzer könnten verwirrt sein, weil sie JS + Browser und JS + Node importieren müssen. Wie in der JavaScript-Welt sagen wir immer nur Browser oder Node env.

Ich denke, Fable.Import.JS sollte in Fable.Core bleiben. Fable zielt schließlich auf JS ab, daher ist es sinnvoll, dass die Kernsprache ohne zusätzliche Pakete verfügbar ist.

Ist es an der Zeit, separate Repos für Fable.Node und Fable.Browser zu erstellen?

Ich dachte daran, alle Bindungen in https://github.com/fable-typed/types zu platzieren, um auf der Arbeit von @mizzle-mo aufzubauen :)

Kann jemand ELI5 dies: Was ist der Vorteil des Monorepo? Was ist los mit Repo per lib?

Okay, ich probiers mal ;)

• Wir haben bereits die Repo-Per-Binding-Lösung ausprobiert , es scheint nicht sehr gut funktioniert zu haben. Folgen wir also DefinitelyTyped (dem abschließenden Beispiel zu dem, was wir tun möchten) und versuchen Sie jetzt den Mono-Repo-Ansatz.
• Sichtbarkeit : Dies ist eigentlich der Hauptgrund, und es scheint für DefinitelyTyped gut funktioniert zu haben. Es hilft Benutzern, die verfügbaren Bindungen leichter zu finden, und anscheinend spricht es auch Mitwirkende an, die mehr Werbung für ihre Bindungen haben können.
• Wartung : Ich weiß, dass dies umstritten ist und von der Person abhängt. Ich persönlich finde den Mono-Repo-Ansatz einfacher, wenn die Projekte stark miteinander verbunden sind und gemeinsame Build-Aufgaben teilen. Ich habe bereits mehrere Bindungen, die in verschiedenen Repos verstreut sind, und die meisten habe ich vergessen. Am Anfang hatte ich gehofft, jede Bindung in einem anderen Repo zu haben, würde den Mitwirkenden helfen, Eigentum zu erlangen, aber ich kenne bisher kein Beispiel für eine beliebte und gut gepflegte Fable-Bindung. Alles in einem einzigen Repo zu haben, erleichtert es einem Team von Mitwirkenden, einen einheitlichen Stil beizubehalten, auf Probleme zu reagieren (auch wenn sie keine bestimmte Bindung erstellt haben) usw.
• Automatisierung : Unser Ziel ist es, die meisten Bindungen zu automatisieren, damit sie einfach von DefinitelyTyped aktualisiert werden können (wie es ursprünglich FunScript tat). Ein Mono-Repo sollte dafür besser geeignet sein.
• Momentum : @mizzle-mo, @jgrund und andere haben in letzter Zeit viel zu den Bindungen beigetragen, also denke ich, dass es gut ist, auf ihrer Arbeit aufzubauen, anstatt alles wieder auseinander zu brechen. (Natürlich würde ich gerne auch ihre Meinung dazu hören, alles in dasselbe Repo zu stecken.)

Bitte beachten Sie, dass ich von reinen Bindungen spreche (in Typescript-Sprache Deklarationen): Typdefinitionen ohne Code. Diese werden nur als .dll s (ohne Quelldateien) verteilt, um die Kompilierung zu beschleunigen. Andere Bibliotheken, die mehr involviert sind, einschließlich Hilfscode (wie Fable.React), sollten wahrscheinlich in ihre eigenen Repos gehen.

Ich habe eine lange Antwort geschrieben, aber scheiß drauf ... Ich kann nichts davon dahinterstecken, aber es ist irrelevant. Eine Sache, die ich sagen möchte, ist: Eigentum ist wichtig – für einige von uns ist dies nicht nur ein Hobby. Ich habe gesehen, wie eine Bindung, die wir früh beigesteuert haben, verschwunden ist, weil das fragliche Repo eine Küchenspüle war, die von einem Komitee verwaltet wurde, und es aus Sicht der Geschäftskontinuität einfach nicht akzeptabel ist.

Natürlich werde ich auf niemanden eine :gun: richten, um sie zu zwingen, ihre Bindungen auf ein Mono-Repo zu schieben :wink: Ich sehe es als vereinbar an, ein einziges Repo mit von der Fable-Community verwalteten Bindungen zu haben, während andere Mitwirkende Pakete auf ihren veröffentlichen und warten eigen.

Es ist möglich, dass das fable-typed Repo derzeit einige Bindungen enthält, die von externen Mitwirkenden erstellt wurden. Ich stimme voll und ganz zu, dass diese Bindungen entfernt werden sollten, wenn die ursprünglichen Ersteller sie lieber in ihren eigenen Repos behalten möchten.

Stimme @alfonsogarciacaro vollkommen zu. Die Idee war, sie alle zusammenzubringen und zu versuchen, eine Community darum herum aufzubauen, während den Verbrauchern ein primärer Ort gegeben wird, an dem sie zuerst suchen können. Ich möchte definitiv niemanden von der Idee abbringen. Vielleicht ist der bessere Ansatz, alle Inhalte von Drittanbietern zu löschen und sie höflich zu fragen. Ich habe jedoch keinen der Autoren in den Dateien geändert und habe auch nicht die Absicht, dies zu tun. Im Moment sehe ich es eher als Fork, um sie zusammenzufassen, aber ich möchte definitiv niemanden verärgern, besonders nicht @et1975

Die Lizenz gibt Ihnen das Recht, also ist das nicht das Problem. Andererseits erfordert Community-Engagement kein Monorepo ... jeder kann eine PR machen. In Bezug auf das Finden der Bindungen ... wie finden Sie irgendwelche F#-Bibliotheken? nuget.org und npm haben beide eine Suche, und dann gibt es da noch die "fantastische" Liste...
Wenn die derzeitige Verwaltung nicht reagiert oder Sie sie in eine andere Richtung lenken möchten, ist dies der Zeitpunkt, an dem Sie sie abzweigen ... Ich kann mir nicht vorstellen, dass etwas anderes nicht kontraproduktiv wäre.

Ich suche sehr selten nach npm und nuget. Normalerweise suche ich zuerst entweder mit Google oder Github.com. Ich möchte nicht nach Nuget suchen, da die Beschreibungen normalerweise scheiße sind. Wenn es um Typen geht, möchte ich wissen, wie kürzlich sie aktualisiert wurden, wie oft sie aktualisiert werden, bevor ich überhaupt versuche, sie zu installieren. Ich könnte aber seltsam sein.

Abgesehen davon war ich besorgt, dass es auch kontraproduktiv sein könnte, wenn Sie zurückgehen und sich die Gitter-Nachrichten ansehen, in denen ich es vorgeschlagen habe. Ich glaube, ich habe tatsächlich die Worte "auf dem Zaun" verwendet, um festzustellen, ob es Zeitverschwendung wäre oder nicht. Ich will überhaupt keine Zeit verschwenden.

Ich bin immer noch auf dem Zaun, dass es Zeitverschwendung ist, weshalb ich nicht daran gearbeitet habe. Idealerweise wäre es automatisiert, sodass ich einfach ts2fable @types/lodash eingeben könnte und ts2fable eine gebrauchsfertige Typdeklaration ausspuckt, die in meinem Projekt verwendet werden kann. An diesem Punkt würden wir überhaupt keine Repos mehr benötigen, außer für Dinge, für die noch keine DefinitelyTyped-Deklaration erstellt wurde. Allerdings weiß ich gar nicht, ob das möglich ist. @et1975 @alfonsogarciacaro Glauben wir, dass wir mit den DefinitelyTyped-Deklarationen an diesen Punkt kommen könnten?

Die Bindungen zu automatisieren ist an sich keine sehr gute Idee. ts2fable gibt Ihnen nur einen Anfang beim Schreiben der Bindungen, und dann möchten Sie den Rest selbst erstellen, ändern, wie Sie die Bibliothek nutzen möchten, sie idiomatischer für F# machen oder Hilfsfunktionen mit Dokumentation bereitstellen usw.

@et1975 Ich denke, das kommt von einem Missverständnis, ich habe vielleicht den Eindruck erweckt, dass ich die Bindungen von jedem Mitwirkenden in ein Mono-Repo stecken wollte. Sollte dies der Fall sein, bitte ich um Entschuldigung, da dies nicht meine Absicht war. Ich dachte hauptsächlich an all die Bindungen, die ich ursprünglich mit ts2fable erstellt (und später angepasst) habe und die derzeit auf fable-compiler.org verstreut sind. Wie oben kommentiert, sollten Bindungen von Drittanbietern nicht in diesem Repo enthalten sein, es sei denn, die ursprünglichen Autoren möchten dies (Forks machen für mich keinen Sinn).

Ich habe einige Male erwähnt, dass ich Fable entpersönlichen möchte, um die Kontinuität des Projekts zu gewährleisten, und dafür möchte ich ein Team aufbauen, in dem Menschen zusammenarbeiten und gemeinsam Entscheidungen treffen (ich denke, wir sind dafür auf dem richtigen Weg). . Aber auf keinen Fall möchte ich, dass Fable ein geschlossenes Ökosystem hat, in dem alles durch ein Komitee geht, jeder sollte frei sein, zu Fable so beizutragen, wie er es für richtig hält.

In Bezug auf die Sichtbarkeit können wir zwar die Nuget-Suche oder Fable-Awesome verwenden, aber ich denke immer noch, dass das Einfügen aller Fable-Compiler.org-Bindungen in dasselbe Repo zu einheitlichen Best Practices beitragen wird, insbesondere an diesem Punkt, an dem wir entscheiden, was der beste Weg ist um die Bindungen zu schreiben.

@mizzle-mo Zur Automatisierung, selbst wenn wir den Punkt erreichen, an dem Übersetzungen mit ts2fable sofort verwendbar sind (was großartig wäre), denke ich immer noch, dass wir unsere eigenen Pakete für die Versionsverwaltung haben möchten. Wenn ich eine Bibliothek erstelle, die beispielsweise von Leaflet-Bindungen abhängt, möchte ich, dass der Verbraucher dieselben Bindungen verwendet (nicht andere, die er aus einer anderen .d.ts-Deklaration oder mit einer anderen Version von ts2fable übersetzt hat).

@alfonsogarciacaro Irgendwelche Updates hier? Ich möchte einige Bindungen für socket.io beitragen, wenn es fertig ist

@jgrund Im Moment habe ich hier nur Fable-Typed/Types gegabelt, da ich keine Rechte habe, auf die ursprünglichen Repos zu pushen. Ich dachte daran, Browser- und Node-Bindungen dorthin zu verschieben und die oben genannten Probleme zu lösen (Bindungen von Drittanbietern zu entfernen) und dann eine PR an Fable-Typed zu senden. Aber wir können auch diskutieren, ob es besser ist, die Bindings in der Fable-Compiler-Org zu belassen :+1:

👍 zum Pushen von Browser-/Knotenbindungen und zum Entfernen von Bindungen von Drittanbietern. Ich denke, das Extrahieren ist sinnvoll, um Fabel zu aktualisieren, ohne an eine bestimmte Bindungsversion gebunden zu sein.