Fable: Serveur de regroupement/dev automatique ?

Créé le 1 avr. 2021 · 3Commentaires · Source: fable-compiler/Fable

Jusqu'à présent, Fable a essayé d'être un pont entre les écosystèmes F # et JS. Et en tant que tel, il n'a pas essayé d'en faire trop et a plutôt laissé l'utilisateur choisir ses outils JS à regrouper, déboguer l'interface, etc. Cependant, depuis que Fable 3 est devenu un outil dotnet "pur" et avec l'apparition de bibliothèques qui ne nécessitent pas de dépendances npm comme Sutil ou Elmish.Snabbdom (ou même React si vous l'utilisez à partir d'un CDN), cela peut être particulièrement utile pour les nouveaux arrivants si Fable pouvait faire (ou au moins invoquer) les opérations de base pour écrire le frontend d'une application Web : groupement et serveur de développement. Pour cela, nous inclurions de nouveaux arguments CLI comme --serve et/ou --bundle .

Écrire notre propre bundler est hors de contrôle. Au début, je pensais que nous pouvions intégrer un bundler dans le package Fable, mais il est probablement plus facile de créer simplement un répertoire .fable-tools caché, d'y installer les outils nécessaires avec npm et de les invoquer si nécessaire. L'idéal serait de s'appuyer sur un bundler avec de bons défauts mais qui peut être personnalisé si nécessaire. La question est, quel bundle utiliser ?

Webpack : l'option la plus étendue et probablement la préférée lorsque l'utilisateur a besoin de personnaliser. Les valeurs par défaut ne suffiront probablement pas, mais nous pourrions générer un webpack.config automatique et, si nécessaire, laisser l'utilisateur le personnaliser. Si je ne me trompe pas, c'est ainsi que fonctionne create-react-app.
Parcel : ce serait un très bon candidat, car il a de nombreux bons défauts, mais ils semblent être bloqués dans la mise à jour v2 pour toujours.
Rollup : nous l'avons parfois utilisé dans Fable pour sa facilité d'utilisation, mais récemment, je le trouve insuffisant et difficile à personnaliser, en particulier le serveur de développement.
Autre? J'ai perdu la trace des nouveaux bundlers comme Snowpack ou peu importe comment ils s'appellent maintenant 😅

Des avis ? N'oubliez pas que cela ne sera que facultatif et que les utilisateurs pourront toujours choisir n'importe quel autre bundle comme c'est le cas actuellement.

discussion

Source

alfonsogarciacaro

❤1

Commentaire le plus utile

Tu as raison. C'est probablement l'une des choses qui m'excitent et que je regrette par la suite 😅 Ok, fermons ça. Maintenant que les choses deviennent plus stables, la façon de simplifier les choses pour les nouveaux arrivants est d'améliorer les modèles :+1 :

alfonsogarciacaro le 2 avr. 2021

❤1 👍1

Tous les 3 commentaires

Je ne pense pas que ce soit une bonne idée. Cela rendra à nouveau floue la frontière entre le monde F # et JavaScript. Semblable à la façon dont c'était dans Fable 2 où les gens avaient du mal à comprendre ce qui était responsable de quoi.

Fable 3 est génial car une fois que vous avez appelé Fable pour générer les fichiers JavaScript, vous êtes directement dans le monde JavaScript. Vous pourrez ainsi trouver toute la documentation que vous souhaitez sur le sujet réalisée par la communauté JavaScript.

Je préférerais largement une documentation bien faite expliquant comment le démarrage et l'arrêt de Fable 3 (compilation de F # en JS) puis expliquerait aux gens d'ici que vous pouvez utiliser l'outil que vous préférez. Et avoir une documentation documentation simple expliquant comment faire puis déléguer l'explication à la documentation de l'outil choisi.

IHMO, les gens doivent comprendre l'écosystème dans lequel ils travaillent. Oui, pour une vitrine vraiment simple, vous pouvez ignorer le fonctionnement de JavaScript, etc. Mais, assez tôt, vous devrez comprendre la situation dans son ensemble afin de pouvoir rédiger votre candidature.

Si nous étions dans une position similaire à celle des langues qui contrôlent 100 % de leur pipeline et de leur écosystème comme Elm, je penserais différemment.

Pour la même raison, je préfère utiliser concurrently pour invoquer Fable et le bundler JavaScript côte à côte. Au lieu de faire invoquer Fable le bundler JavaScript.

Ce n'est pas grand-chose, mais cela "montre" qu'ils travaillent côte à côte sans magie. Lorsque nous exécutons dotnet fable --run XXX , il n'est pas clair que la commande ne sera exécutée qu'une seule fois, même si vous êtes en mode veille.

IHMO, c'est dans tous ces détails mineurs que nous pouvons gagner en clarté/transparence sur la façon dont les choses fonctionnent/fonctionnent.

MangelMaxime le 1 avr. 2021

👍2

Mon opinion personnelle, telle qu'exprimée dans les discussions passées sur le sujet, est qu'il est très logique d'adopter et de rester dans les objectifs de conception que d'autres transpilateurs comme TypeScript ont également, en particulier la section "non-objectifs" (c'est-à-dire le "nous section "je ne veux pas faire ça"), et sur ce sujet particulier, le "non-but" le plus proche est le numéro 4.