Fable: Ramener le chargeur de fable ?

À quoi ressemble le flux de travail que vous avez en tête, si nous n'avons pas de chargeur ? Fable compilera-t-il simplement le code F# dans un répertoire de sortie, puis Webpack ou tout autre bundler prendra le relais à partir de là ?

Je n'ai pas regardé les progrès de Nagareyama ces derniers temps, alors pardonnez-moi si cela a déjà été clarifié quelque part.

Faire en sorte que Fable soit simple à configurer sans avoir à utiliser un modèle serait certainement très agréable.

Salut @inosik ! Le but de Nagareyama est de simplifier Fable en supprimant le mélange .NET/JS dans le compilateur lui-même. Ainsi, Fable deviendra un outil dotnet "pur" distribué via Nuget et sa seule responsabilité sera de cracher des fichiers JS (en évitant une interaction complexe avec les outils JS). Donc, pour compiler un projet F# (étant donné sa compatibilité avec Fable), la seule chose que vous aurez à faire est de :

dotnet tool install fable
dotnet fable src/Client

Vous pouvez définir un répertoire de sortie si vous le souhaitez, mais par défaut, Fable placera les fichiers .js à côté de ceux .fs.

Ensuite, les utilisateurs peuvent faire tout ce dont ils ont besoin avec les fichiers JS. Dans le cas courant de les regrouper avec webpack, ils n'ont qu'à définir le dernier fichier .js généré comme entrée dans le webpack.config (aucune dépendance npm supplémentaire comme fable-loader n'est nécessaire). Pour plus de simplicité, Fable peut exécuter une commande après la compilation comme dans dotnet fable src/Client --run webpack ou dotnet fable watch src/Client --run webpack-dev-server

J'aime la nouvelle approche.
Ce changement affecterait-il les optimisations de vitesse à l'avenir, comme l'HMR ? Il n'y a pas une sorte de perte de simultanéité ?

Je ne pense pas que cela devrait affecter l'HMR, mais veuillez signaler si vous voyez quelque chose. Il est vrai qu'en utilisant --run Webpack ne démarrera pas tant que la compilation ne sera pas terminée, pour cela il y a l'option --runFast qui exécutera le sous-processus avant la compilation F#/Fable. Ainsi, si les fichiers JS existent déjà (généralement à partir d'une compilation précédente), Webpack peut fonctionner en parallèle et le temps de 0 pour que le serveur fonctionne est essentiellement réduit au temps de regroupement. Et une fois Fable terminé en parallèle, les compilations de montres sont très rapides comme d'habitude.

J'essaie actuellement de créer une application avec un backend utilisant Azure Functions (à héberger sur des sites Web statiques Azure) et ce qui me pose problème, c'est de configurer des redirections pour l'environnement de développement local lors de l'utilisation de colis comme indiqué dans la fable minimale3 Exemple.

Personnellement, je serais très heureux de me débarrasser de webpack et de simplifier la pile, mais ces quelques conseils sur la façon de configurer quelque chose comme une application de pile SAFE seraient très utiles. Si cela pouvait être fait sans fable-loader, alors il devrait être acceptable de ne pas l'avoir.

Des conseils seraient appréciés :-)

@uxsoft Avez-vous déjà vu la page _API Proxy_ dans la documentation sur les colis ? Mais il semble que ce soit une fonctionnalité à venir de Parcel v2, qui n'est apparemment pas encore sortie. Il semble que Parcel n'ait pas de proxy intégré dans la v1.

J'ai trouvé un article de blog d'il y a un an , où l'auteur décrit comment configurer un environnement de développement avec Parcel et un serveur Express qui agit comme un proxy. Peut-être que cela aide.

@uxsoft Aussi, juste pour mettre à jour votre projet sans toucher Webpack, vous pouvez suivre cet exemple : https://github.com/MangelMaxime/fulma-demo/pull/43

Eh bien, dans ce cas, il ne devrait pas y avoir besoin de fable-loader si nous pouvons de toute façon diriger vers le serveur de développement webpack, non?

Oui c'est vrai. Le seul but du "nouveau" chargeur de fable serait de permettre aux utilisateurs de passer à Fable 3 sans toucher à leur configuration de pack Web ou à leur script de construction, mais je préférerais personnellement que les gens s'habituent à la nouvelle façon car elle est alignée avec d'autres F # outils et pour éviter d'avoir à maintenir/documenter deux façons d'utiliser Fable.

Dans tous les cas, d'après les commentaires reçus, il semble que les utilisateurs soient satisfaits du changement, je vais donc fermer ce problème pour l'instant pour éviter toute confusion. Nous pourrons revoir plus tard si besoin.

Le nouveau fable-loader pourrait être utile au cas où certains outils JS utiliseraient la configuration de webpack comme point d'entrée/entrée. Par exemple - Cloudflare Workers : https://developers.cloudflare.com/workers/cli-wrangler/webpack

@Krzysztof-Cieslak Déprécier fable-loader ne signifie pas que vous ne pouvez plus utiliser Fable avec webpack, cela signifie simplement qu'il devient plus facile à utiliser dans webpack car il devient simplement ceci:

• dotnet fable déclenche Fable en tant qu'outil CLI dotnet
• Fable compile les fichiers F# en fichiers JS (modules)
• Webpack les regroupe

À la place de:

• fable-loader déclenche Fable comme chargeur de module d'entrée
• Fable compile les fichiers F# dans JSONified Babel AST (relativement lent)
• babel-loader prend JSON babel AST et génère du code JS
• Webpack les regroupe

J'ai soulevé le problème avec @alfonsogarciacaro parce que je pensais que cela rendrait la migration plus facile si nous gardions fable-loader et mettions simplement à jour fablec-compiler (le package npm) vers le dernier Fable mais ce serait peut-être beaucoup mieux si nous simplifiions tout nos modèles et supprimé complètement ces chargeurs (fonctionne également bien avec d'autres paquets comme les colis)

Bien sûr, cela signifie "juste" que je dois mettre des étapes supplémentaires dans mon processus de construction pour quelque chose qui était autrefois une seule étape.

Votre appel si c'est un compromis raisonnable / haussement d'épaules

L'étape de construction n'est toujours qu'une seule commande, sauf qu'elle ne nécessite désormais pas de chargeurs de webpacks supplémentaires et peut facilement être utilisée avec différents bundlers.

# compile project using Fable
dotnet fable ./src 

# compile project then trigger bundler (production build)
dotnet fable ./src --run webpack

# build in watch mode
dotnet fable watch ./src

# build in watch mode and trigger a bundler after compilation
dotnet fable watch ./src --run webpack-dev-server

Webpack n'a besoin de connaître que le fichier d'entrée JS généré à partir de Fable ( {lastFile}.fs.js ) en tant que fichier d'entrée pour le regroupement et la minification. fable-loader et babel-loader ne sont pas nécessaires.

@alfonsogarciacaro Existe-t-il un dotnet fable run équivalent à dotnet run qui déclenche automatiquement node {lastFile}.fs.js fois la compilation terminée avec succès ? Peut-être une commande intéressante pour montrer Fable 🤔

L'étape de construction n'est toujours qu'une commande

Pas vraiment dans le cas des outils CF Workers - il s'agissait d'un seul appel à wrangler dev (qui sous le capot utilisait webpack d'une manière ou d'une autre, qui sous le capot exécutait fable avec le chargeur). Maintenant, il compilera d'abord la fable, puis appellera wrangler.

Encore une fois, ce n'est pas grave - je donne plutôt un exemple où l'ancien flux de travail convenait mieux.

J'aimais beaucoup le modèle précédent aussi mais maintenant que j'ai essayé les nouveautés, j'apprécie vraiment l'augmentation des performances de la compilation lorsque tous ces frais généraux sont supprimés

Est-ce que quelque chose comme dotnet fable dev --run wrangler dev fonctionne ? En théorie, nous pourrions avoir un nouveau chargeur de fables qui appelle simplement dotnet fable mais il peut y avoir des problèmes avec le démarrage/l'arrêt des processus, l'observateur, etc. Je préfère donc l'éviter.

dotnet fable watch src --outDir tmp --run wrangler dev semble faire ce que je veux (c'est-à-dire à la fois fable et wrangler en mode montre).

Il y a un problème avec le processus wrangler qui n'est pas tué après avoir tué le processus dotnet fable, mais ce n'est pas un gros problème.

Frais! Hmm, il y a eu des rapports sur un problème similaire mais je pensais qu'ils étaient corrigés. Pouvez-vous s'il vous plaît jeter un oeil à #2212? Utilisez-vous Windows ? Je ne fais qu'accrocher les événements de terminaison dans Windows parce que je n'ai pas vu ce problème dans macOS, mais nous devrons peut-être le faire également : https://github.com/fable-compiler/Fable/blob/111a0b2175bf605594817f849109fedef04eb6f3/src/ Fable.Cli/Util.fs#L127 -L136