Fable: Ramener la prise en charge de la carte source

Fable 3 ne sera-t-il plus distribué via le package fable-compiler (utilisé avec fable-loader ) ? 😱 Je comprends que l'application Fable pure a une meilleure expérience utilisateur que fable-splitter pour créer des applications node.js, mais la suppression de la distribution npm serait un énorme changement partout et honnêtement un peu pénible pour travailler avec: modèles, bibliothèques et projets. C'est tellement plus facile de dire : npm upgrade fable-compiler et il sera prêt à fonctionner (espérons-le sans casser les changements)

Depuis qu'ils ont corrigé l'épinglage de version des outils locaux, la distribution de Fable 3 en tant qu'outil dotnet est probablement la voie à suivre, comme le font tous les autres outils F# (Paket, Fake, Fantomas, Femto, Snowflaqe). Garder fable-compiler en tant que distribution parallèle sera probablement plus déroutant pour les utilisateurs que d'avoir une coupe claire.

Je préférerais que les gens s'habituent à appeler Fable comme un outil dotnet 😸 Mais... Je comprends que la mise à jour de tous les tutoriels, projets, modèles est pénible (comme par le passé). Nous pourrions donc envisager de publier une nouvelle version majeure de fable-loader qui invoque simplement l'outil dotnet Fable. Les étapes de mise à niveau (lorsque des versions stables sont publiées) seraient alors simplement :

dotnet tool install fable
npm upgrade fable-loader

Probablement aussi en ajoutant *.fs.js à .gitignore. fable-compiler peut être désinstallé ou non, il ne sera tout simplement pas invoqué. À quoi cela ressemblerait-il ? Et est-ce que quelqu'un se porterait volontaire pour entretenir le nouveau chargeur de fables ? ??

Garder fable-compiler en tant que distribution parallèle sera probablement plus déroutant pour les utilisateurs que d'avoir une coupe claire.

Garder la rétrocompatibilité avec le moins de changements requis est vraiment important et ferait le bonheur de beaucoup de gens. À l'heure actuelle, cela ressemble plus à une rétrogradation en raison du niveau d'indirection introduit (fable a été appelé en premier, puis webpack) et webpack s'attendra à ce que les fichiers n'existent qu'après que Fable les ait compilés alors qu'à l'heure actuelle, il est totalement _invisible_ et ressemble beaucoup à comment TypeScript est intégré aux projets existants.

J'aime l'outil CLI pour simplifier la création et l'exécution d'applications node.js au lieu d'utiliser fable-splitter

Depuis qu'ils ont corrigé l'épinglage de version des outils locaux, la distribution de Fable 3 en tant qu'outil dotnet est probablement la voie à suivre

C'est peut-être une idée de faire un sondage (sur twitter par exemple) pour demander aux utilisateurs existants ce qu'ils préféreraient ?

Déplacer la discussion vers #2195 car ce problème concerne les cartes sources et cela peut être déroutant pour les contributeurs.

Sans cartes source, il n'y aura aucun moyen d'intégrer le débogage étape par étape dans VSCode via launch.json , est-ce correct ?

Je suppose que la plupart des utilisateurs frontaux préféreront de toute façon utiliser un débogueur à déplacement dans le temps.

Vous pouvez toujours utiliser le débogueur VSCode, mais les points d'arrêt ne peuvent être atteints que dans les fichiers JS générés. J'ai utilisé fréquemment les cartes source à la fois dans VSCode et Chrome (bien que parfois la modification des noms rende difficile l'identification des valeurs, ce que nous essayons d'améliorer dans Nagareyama), mais je ne sais pas si de nombreux autres utilisateurs l'ont fait.

Je n'ai pas encore commencé de code à ce sujet mais je garde un œil dessus. Ma première tendance est de faire un portage direct de mozilla/source-map en supposant que c'est précisément ce qui est nécessaire mais alors je me demande si nous ferions mieux d'utiliser C# ou F# pour le port, je préférerais l'écrire moi-même en F#, mais il y a certains avantages à choisir C#. Dans tous les cas, le portage de la bibliothèque fournirait une implémentation .NET native pour travailler avec des sources-maps en général, ce qui peut être utile pour l'écosystème .NET. Pour l'instant, j'ai bifurqué le projet avec l'intention de donner une chance à cette option dans mon temps libre limité.

Une autre option qui m'est peut-être venue à l'esprit serait d'utiliser la prise en charge de WebAssembly pour la bibliothèque mozilla/source-map pour compiler en WebAssembly, puis d' intégrer le WASM dans une bibliothèque .NET à l'aide de Wasmtime . Je ne suis pas très familier avec cette option, mais si cela fonctionne et fonctionne raisonnablement, cela peut être un moyen plus simple de garder l'implémentation synchronisée avec la bibliothèque source-maps d'origine en Javascript.

Une autre option qui m'est peut-être venue à l'esprit serait d'utiliser la prise en charge de WebAssembly pour la bibliothèque mozilla/source-map pour compiler en WebAssembly, puis d' intégrer le WASM dans une bibliothèque .NET à l'aide de Wasmtime . Je ne suis pas très familier avec cette option, mais si cela fonctionne et fonctionne raisonnablement, cela peut être un moyen plus simple de garder l'implémentation synchronisée avec la bibliothèque source-maps d'origine en Javascript.

On dirait presque que nous avons besoin d'un transpileur Java-script vers F#...

Sérieusement, une bibliothèque de cartes source F# serait une bonne idée.

https://github.com/delneg/source-map-sharp
J'ai commencé à traduire https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js
là, pas du tout le meilleur code mais j'ai essayé de faire une traduction directe

C'est super @delneg , merci beaucoup ! Je pense qu'une traduction directe fonctionne mieux même si ce n'est pas idiomatique F# au cas où nous aurions besoin de synchroniser les mises à jour de la bibliothèque d'origine plus tard :+1:

J'ai fait du travail (ici https://github.com/delneg/source-map-sharp), mais j'aurais peut-être besoin d'aide avec les fonctions "util.js" telles que util.join , util.relative qui sont utilisés dans source-map-generator.js

Je suis presque sûr que nous n'aurons pas besoin de util.getArg cause de la sécurité du type F#, et je suis presque sûr que nous n'aurons pas besoin de util.toSetString parce que c'est un hack pour éviter les bogues liés à '__proto__'.

S'il vous plaît dites-moi aussi si nous allons l'utiliser comme CLI ou ... ?

Merci @delneg ! Je vais jeter un œil ce week-end et j'essaierai de PR ces fonctions :+1: Oui, la bibliothèque sera utilisée à partir de Fable.Cli. Si vous le publiez en tant que bibliothèque indépendante, nous pouvons simplement référencer votre package Nuget.

J'ai fait la plupart de SourceMapNode, SourceMapGenerator et créé un fichier README.md pour présenter les progrès actuels.
En outre, vous pouvez trouver le type d'aide dont vous avez besoin au guichet automatique.

Selon les documents ici https://github.com/mozilla/source-map#generating -a-source-map , ce que nous avons maintenant est suffisant pour générer des cartes sources ... (bien que je ne sais pas exactement comment au m)

C'est fantastique @delneg ! Je l'ai essayé rapidement et semble fonctionner :+1: Je vais maintenant essayer d'activer le débogage.

C'est gentil, peux-tu proposer les prochaines étapes ?
C'est-à-dire publier du nuget ou écrire des tests ou autre chose (peut-être quelque chose du README dans le repo)
(PS bien que je n'ai jamais fait de publication nuget, et devrait probablement être fait en utilisant un compte fable)
PPS pas étonnant que cela ait fonctionné tout de suite, je m'y suis habitué en utilisant F #

Les prochaines étapes devraient être de tester que les sourcesmaps fonctionnent réellement pour le débogage et de faire le travail supplémentaire dans Fable (en ajoutant l'option --sourceMap , en l'enregistrant dans un fichier`. Je peux le faire de mon côté. Je vous enverrai également un PR pour peaufiner un peu l'API (comme utiliser des arguments facultatifs au lieu d'options explicites).

Pour le moment, nous n'avons pas de compte Fable Nuget, nous publions les packages avec notre compte personnel et généralement 2-3 propriétaires juste au cas où. Si vous créez un compte sur nuget.org et générez un jeton, il est facile d'automatiser la publication . Je peux PR le script pour ça. Vous pouvez également m'ajouter comme collaborateur du package si vous le souhaitez.

Ok, je regarderai les trucs de Nuget Publishing quand j'aurai le temps
Aussi, je vous ai ajouté en tant que collaborateur au dépôt
Si je peux, je vais essayer de peaufiner un peu l'API aussi, et essayer d'ajouter quelques tests pour SourceGenerator

J'ai commencé à ajouter plus de tests pour SourceMapGenerator, ils ont révélé des bogues qui se cachaient.
Certains sont maintenant corrigés, mais avant il semble que tous doivent être corrigés - sinon les mappages peuvent ne pas fonctionner dans certains cas
Il est donc un peu tôt pour publier nuget atm
Si quelqu'un veut aider, jetez un œil aux tests qui échouent ( dotnet test )

https://www.nuget.org/packages/source-map-sharp/
J'ai publié le package nuget, les tests de génération de mappages réels liés à SourceMapGenerator (fonction SerializeMapping) sont effectués et les bogues sont corrigés, cela devrait donc fonctionner correctement.
Je vais continuer sur SourceNode et d'autres trucs, et ce serait génial si some1 pouvait aider avec util.relative / util.join

C'est super @delneg ! Merci beaucoup pour cela! Je me remets lentement au travail après les vacances, donc je vais essayer de pousser une version bêta de Fable 3.1 avec la prise en charge de la carte source en utilisant votre package lorsque cela est possible :+1:

Je pense que Fable lui-même n'a pas besoin de SourceNode, mais si vous préférez l'ajouter pour être complet, cela peut aider d'autres utilisateurs de la bibliothèque. À propos de util.relative/join , je vais également essayer d'envoyer un PR à votre projet, mais étant donné que cela fonctionnera sur .NET, je suppose que vous devriez pouvoir utiliser System.IO.Path.GetRelativePath et System.IO.Path.Combine : https://docs.microsoft.com/en-us/dotnet/api/system.io.path?view=net-5.0

Malheureusement, GetRelativePath n'est pas disponible pour netstandard2.0 (voir https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getrelativepath?view=net-5.0#applies -à)
La solution peut être de passer à netstandard2.1 (je ne sais pas si c'est une bonne solution)
En ce qui concerne util.join - après avoir examiné toutes les occurrences, je pense qu'il n'est utilisé que dans les cas liés à consumer (que je ne ferai pas atm), donc en fait ce n'est pas nécessaire pour le moment.

PS En ce qui concerne le SourceNode, etc. - je pense que si nous faisons un portage .net de sourcemap, faisons-le correctement en implémentant tout ce qu'il y a, même s'il n'est pas utilisé maintenant, cela peut être nécessaire dans un an ou deux

.Net Standard 2.1 laisserait les choses liées à Mono dans la poussière (c'est-à-dire les choses Xamarin). Mais pour le cas d'utilisation de Fable, c'est probablement bien car il s'agit d'une dépendance de développement uniquement et le framework ne signifie de toute façon rien au moment de l'exécution.

Donc, si la bibliothèque ne doit être utilisée que dans Fable, 2.1 convient, mais si vous voulez une compatibilité maximale avec d'autres éléments .Net, 2.0 est plus idéal pour cela.

FWIW, quelqu'un en a fourni une implémentation simple sur StackOverflow : https://stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

.Net Standard 2.1 laisserait les choses liées à Mono dans la poussière (c'est-à-dire les choses Xamarin). Mais pour le cas d'utilisation de Fable, c'est probablement bien car il s'agit d'une dépendance de développement uniquement et le framework ne signifie de toute façon rien au moment de l'exécution.

Donc, si la bibliothèque ne doit être utilisée que dans Fable, 2.1 convient, mais si vous voulez une compatibilité maximale avec d'autres éléments .Net, 2.0 est plus idéal pour cela.

FWIW, quelqu'un en a fourni une implémentation simple sur StackOverflow: stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

Je pense que pour l'instant je vais passer à 2.1 et laisser une note dans README pour les utilisateurs potentiels de netstandard2.0.
Si quelqu'un en a besoin pour fonctionner sous 2.0, nous aurons une solution de secours de Stackoverflow.

Edit: téléchargé 1.0.1 https://www.nuget.org/packages/source-map-sharp/1.0.1 avec netstandard2.1

Une autre option serait d'exclure conditionnellement (avec #if) les éléments qui reposent sur GetRelativePath via le multitargeting, afin que tout le reste soit disponible sur la norme .Net 2.0.

Une autre option serait d'exclure conditionnellement (avec #if) les éléments qui reposent sur GetRelativePath via le multitargeting, afin que tout le reste soit disponible sur la norme .Net 2.0.

Cela semble être une complication excessive pour un problème d'URL relative simple (uniquement pour l'atm qui nécessite GetRelativePath )

Fable en tant qu'outil dotnet est netcoreapp3.1, vous pouvez donc cibler netstandard2.1, vous devrez peut-être normaliser le chemin lorsqu'il est exécuté sous Windows comme Path.GetRelativePath(path, pathTo).Replace('\\', '/') .

Si vous souhaitez que la bibliothèque cible netstandard2.0 pour une compatibilité maximale, comme le souligne @jwosty , nous avons en fait notre propre implémentation. Je n'y ai pas touché depuis un moment mais ça a l'air de bien fonctionner : https://github.com/fable-compiler/Fable/blob/ba509a94a50522794d3e60f27dd826bb5602eca1/src/Fable.Transforms/Global/Prelude.fs#L508 -L555

De plus, Path.GetRelativePath n'ajoute pas de point toujours devant le chemin relatif :

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

La période est probablement nécessaire pour les URL des sourcesmaps, vous devrez donc peut-être également faire quelque chose comme dans les lignes 545-548 de l'extrait ci-dessus lors de la normalisation du chemin.

Je vais vérifier les choses ci-dessus et adapter les tests de JS (il y en a pas mal dans test-util.js), utilisera probablement notre propre implémentation.
De plus, il reste quelques questions :
1) Peut-être devrions-nous migrer la discussion vers les problèmes de référentiel source-map-sharp ?
2) Prévoyons-nous d'utiliser une sorte de compilation WASM pour ce projet (y a-t-il une raison de le faire, car je ne connais pas la raison de l'utilisation de WASM dans le référentiel source-map d'origine) ?
3) Y a-t-il autre chose nécessaire pour que Fable commence à utiliser source-map-sharp, le cas échéant (y compris des documents, des tests, des API supplémentaires, etc.)

Edit: OK, c'était facile, j'ai déjà ajouté le Util.getRelativePath personnalisé, ajouté des tests et après de légères modifications, ils sont passés au vert.
Doit-on alors revenir à netstandard2.0 et/ou publier 1.0.2 nuget ?

Génial @delneg ! 👏 🚀 👏

1. Oui, il est logique de déplacer la discussion vers le référentiel source-map-sharp :+1: Veuillez me mentionner lorsque vous avez besoin de ma contribution afin que je reçoive la notification.
2. Je n'ai pas vérifié l'utilisation de WASM dans la carte source d'origine, mais je suppose qu'ils l'utilisent dans des environnements prenant en charge WASM pour accélérer les calculs numériques. Je ne pense pas que nous ayons à nous en soucier dans le port .NET.
3. Ça devrait aller, je n'ai pas eu beaucoup de temps ces jours-ci, mais j'essaierai de publier une version bêta 3.1 bientôt avec des cartes sources 💪 Vous pouvez continuer et publier la 1.0.2 afin que nous l'utilisions dans la version bêta.

La version bêta de Fable 3.1 est publiée avec le support de la carte source grâce au travail fantastique de https://twitter.com/FableCompiler/status/1347421291502997504

Fantastique - d'un utilisateur de Fable : merci beaucoup pour ce @delneg !

Incroyable incroyable incroyable !

Génial @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.

Merci pour votre aide.
Je ferai de mon mieux pour maintenir source-map-sharp à l'avenir, et je suis content que cela fonctionne maintenant.
1) J'écrirai alors dans les problèmes du dépôt, et si quelqu'un a des questions, etc. - veuillez ouvrir un problème dans source-map-sharp
2) Oui, je suppose qu'ils ont utilisé WASM pour améliorer les performances.
J'ai essayé de faire fonctionner la version WASM de source-map-sharp, mais l'état de la compilation WASM dans .net semble horrible et très difficile à utiliser (certains travaux sont effectués dans le projet Uno.Platform.Bootstrap, mais en le regardant c'est le code source m'a beaucoup déçu)
Dans la mesure où source-map-sharp reste une application .NET, si nous avons besoin de plus de performances, nous pouvons toujours regarder Spanet d'autres éléments .NET pour le rendre plus rapide
3) J'ai publié la 1.0.2 et j'ai vu que vous l'aviez déjà utilisé, c'est tout.
J'essaierai de continuer à publier Nuget's à l'avenir si nous trouvons des bogues, etc. (et essayez de ne pas changer l'API)

Pour tous ceux qui ne voient toujours pas les cartes sources après avoir appliqué les instructions de @alfonsogarciacaro , essayez de nettoyer vos fichiers de sortie (y compris tous les fichiers .fs.js ) et relancez votre build. Il m'a fallu un certain temps pour comprendre cela, car la simple reconstruction sans nettoyage n'a pas fonctionné.

En dehors de cela, merci à toutes les personnes impliquées d'avoir ramené cette fonctionnalité géniale 👍

Super travail! Je suis revenu aujourd'hui pour voir si je pouvais reprendre ce projet et à mon grand plaisir il est déjà terminé. J'ai archivé le référentiel que j'avais commencé à échafauder pour cet effort et https://github.com/delneg/source-map-sharp pour le moment. Encore un super boulot !