Fable: Créer un package Fable.Import

@alfonsogarciacaro Fable.Core.Extensions.fs dépend également de Fable.Import.JS.Promise. Nous pouvons soit conserver l'intégralité de Fable.Import.JS, soit uniquement la partie Promise/PromiseLike, qui est peu susceptible de changer.

Je pense que ce serait une bonne idée.

J'opterais pour trois packages différents, mais les utilisateurs pourraient être confus quant à la nécessité d'importer JS + Browser et JS + Node. Comme dans le monde JavaScript, nous disons toujours simplement Browser ou Node env.

Je pense que Fable.Import.JS devrait rester dans Fable.Core. Fable cible JS après tout, il est donc logique que le langage de base soit disponible sans aucun package supplémentaire.

Il est temps de créer des dépôts séparés pour Fable.Node et Fable.Browser ?

Je pensais mettre toutes les liaisons dans https://github.com/fable-typed/types pour construire sur le travail de @mizzle-mo :)

Quelqu'un peut-il ELI5 ceci : quel est l'avantage du monorepo ? Quel est le problème avec le repo par lib ?

Ok je vais m'y mettre ;)

• Nous avons déjà essayé la solution repo per binding , cela ne semble pas avoir très bien fonctionné. Alors suivons DefinitelyTyped (l'exemple le plus proche de ce que nous voulons faire) et essayons maintenant l'approche mono repo.
• Visibilité : C'est en fait la principale raison, et cela semble avoir bien fonctionné pour DefinitelyTyped. Cela aide les utilisateurs à trouver plus facilement les liaisons disponibles et, apparemment, cela attire également les contributeurs qui peuvent avoir plus de publicité pour leurs liaisons.
• Maintenance : Je sais que cela est discutable et que cela dépend de la personne, personnellement je trouve l'approche mono-repo plus facile lorsque les projets sont fortement liés et partagent des tâches de construction communes. J'ai déjà plusieurs liaisons éparpillées dans différents dépôts et j'en ai oublié la plupart. Au début, j'espérais que chaque liaison dans un référentiel différent aiderait les contributeurs à devenir propriétaires, mais je ne connais jusqu'à présent aucun exemple de liaison Fable populaire et bien entretenue. Avoir tout dans un seul dépôt permet à une équipe de contributeurs de garder plus facilement un style uniforme, de répondre aux problèmes (même s'ils n'ont pas créé de liaison spécifique), etc.
• Automatisation : Notre objectif est d'avoir la plupart des liaisons automatisées afin qu'elles puissent être facilement mises à jour à partir de DefinitelyTyped (comme FunScript l'a fait à l'origine). Un dépôt mono devrait être mieux adapté à cela.
• Momentum : @mizzle-mo, @jgrund et d'autres ont beaucoup contribué aux fixations récemment, donc je pense qu'il est bon de s'appuyer sur leur travail au lieu de tout casser à nouveau. (Bien sûr, j'aimerais aussi entendre leur opinion sur le fait de tout mettre dans le même dépôt.)

Veuillez noter que je parle de liaisons pures (dans le langage Typescript, déclarations): définitions de type sans code. Ceux-ci seront distribués uniquement en tant que .dll s (sans les fichiers source) pour accélérer la compilation. D'autres bibliothèques plus impliquées, y compris le code d'assistance (comme Fable.React) devraient probablement aller dans leurs propres dépôts.

J'ai écrit une longue réponse, mais merde... Je ne peux rien derrière tout cela, mais ce n'est pas pertinent. Une chose que je dirai est la suivante : la propriété est importante - pour certains d'entre nous, ce n'est pas seulement un passe-temps. J'ai vu une liaison que nous avons contribuée au début disparaître parce que le repo en question était un évier de cuisine géré par un comité et ce n'est tout simplement pas acceptable du point de vue de la continuité des activités.

Bien sûr, je ne pointerai un :gun: sur qui que ce soit pour les forcer à pousser leurs liaisons vers un mono-dépôt :wink: Je vois compatible le fait d'avoir un seul dépôt avec les liaisons maintenues par la communauté Fable tandis que d'autres contributeurs publient et maintiennent des packages sur leur propre.

Il est possible qu'à l'heure actuelle, le dépôt de type fable contienne des liaisons créées par des contributeurs externes. Je suis totalement d'accord que ces liaisons devraient être supprimées si les créateurs originaux préfèrent les conserver dans leurs propres dépôts.

Totalement d'accord avec @alfonsogarciacaro. L'idée était de les rassembler et d'essayer de créer une communauté autour d'elle tout en donnant aux consommateurs un premier endroit où regarder en premier. Je ne veux absolument pas détourner l'idée de qui que ce soit. La meilleure approche consiste peut-être à supprimer tous les éléments tiers et à leur demander poliment. Cependant, je n'ai changé aucun des auteurs dans les fichiers et je n'ai aucune intention de le faire. En ce moment, je le vois plus comme un fork pour les agréger, mais je ne veux certainement pas contrarier qui que ce soit, en particulier @et1975

La licence vous donne le droit, donc ce n'est pas le problème. D'un autre côté, l'implication de la communauté ne nécessite pas de monorepo... n'importe qui peut faire un PR. En termes de recherche des liaisons... comment trouvez-vous des bibliothèques F# ? nuget.org et npm ont tous deux la recherche, et puis il y a la liste "impressionnante"...
Lorsque l'intendance actuelle ne répond pas, ou que vous voulez l'emmener dans une direction différente, c'est là que vous la bifurquez... Je ne vois pas comment quoi que ce soit d'autre ne serait pas contre-productif.

Je recherche npm et nuget très rarement. Habituellement, je recherche d'abord en utilisant Google ou Github.com. Je ne veux pas chercher de nuget car les descriptions sont généralement nulles. En ce qui concerne les types, je veux savoir à quelle date ils ont été mis à jour, à quelle fréquence ils sont mis à jour avant même d'essayer de l'installer. Je pourrais être bizarre cependant.

Cela étant dit, je craignais également que cela ne soit contre-productif si vous revenez en arrière et regardez les messages Gitter où je l'ai proposé. Je pense que j'ai en fait utilisé les mots "sur la clôture" pour savoir si ce serait une perte de temps ou non. Je ne veux pas du tout perdre de temps.

Je suis toujours sur le point de dire que c'est une perte de temps, c'est pourquoi je n'ai pas travaillé dessus. Idéalement, il serait automatisé, donc je pourrais simplement taper ts2fable @types/lodash et avoir ts2fable cracher une déclaration de type prête à l'emploi prête à être utilisée dans mon projet. À ce stade, nous n'aurions plus besoin de repos du tout, sauf pour les choses qui n'ont pas de déclaration DefinitelyTyped déjà créée. Cependant, je ne sais même pas si c'est possible. @et1975 @alfonsogarciacaro Pensons -nous pouvoir en arriver là avec les déclarations DefinitelyTyped ?

L'automatisation des liaisons n'est en soi pas une très bonne idée. ts2fable ne vous donnera qu'un début pour écrire les liaisons, puis vous voudrez créer le reste vous-même, changer la façon dont vous voulez utiliser la bibliothèque, la rendre plus idiomatique F # ou fournir des fonctions d'assistance avec la documentation, etc.

@et1975 Je pense que cela vient d'un malentendu, j'ai peut-être donné l'impression que je voulais mettre dans un repo mono les bindings de chaque contributeur . Si c'est le cas, je m'en excuse car ce n'était pas mon intention. Je pensais principalement à toutes les liaisons que j'ai créées à l'origine avec ts2fable (et modifiées plus tard) et qui sont actuellement dispersées sur fable-compiler.org. Comme indiqué ci-dessus, les liaisons tierces ne devraient pas figurer dans ce référentiel à moins que les auteurs originaux ne le souhaitent (les fourches n'ont aucun sens pour moi).

J'ai mentionné quelques fois que je voulais dépersonnaliser Fable pour assurer la continuité du projet et pour cela j'aimerais construire une équipe où les gens travaillent et prennent des décisions ensemble (je pense que nous sommes sur la bonne voie pour cela) . Mais je ne veux en aucun cas que Fable ait un écosystème fermé où tout passe par un comité, tout le monde devrait être libre de contribuer à Fable de la meilleure façon qu'il juge appropriée.

À propos de la visibilité, il est vrai que nous pouvons utiliser la recherche Nuget ou fable-awesome, mais je pense toujours que mettre toutes les liaisons fable-compiler.org dans le même référentiel aidera à uniformiser les meilleures pratiques, en particulier à ce stade lorsque nous décidons quelle est la meilleure façon pour écrire les reliures.

@mizzle-mo Sur l'automatisation, même si nous atteignons le point où les traductions avec ts2fable sont immédiatement utilisables (ce qui serait génial), je pense toujours que nous voudrions avoir nos propres packages pour la gestion des versions. Si je crée une bibliothèque qui dépend, par exemple, des liaisons Leaflet, je souhaite que le consommateur utilise les mêmes liaisons (pas d'autres qu'ils ont traduites à partir d'une déclaration .d.ts différente ou avec une version différente de ts2fable).

@alfonsogarciacaro Des mises à jour ici ? J'aimerais contribuer à quelques liaisons pour socket.io quand il sera prêt

@jgrund Pour l'instant, je viens de bifurquer fable-typed/types ici car je n'ai pas le droit de pousser vers les dépôts d'origine. Je pensais y déplacer les liaisons de navigateur et de nœud et résoudre les problèmes mentionnés ci-dessus (supprimer les liaisons tierces), puis envoyer un PR à fable-typé. Mais nous pouvons également discuter s'il est préférable de conserver les liaisons dans l'organisation fable-compiler :+1 :

👍 pour pousser les liaisons navigateur / nœud et supprimer celles de tiers. Je pense que les extraire est logique en termes de mise à jour de fable sans être épinglé à une version de liaison spécifique.