Fable: Recuperar la compatibilidad con mapas de origen

¿Fable 3 ya no se distribuirá a través del paquete fable-compiler (utilizado junto con fable-loader )? 😱 Entiendo que la aplicación pura de Fable tiene una mejor experiencia de usuario que fable-splitter para crear aplicaciones node.js, pero eliminar la distribución npm sería un gran cambio en todas partes y, honestamente, un poco de dolor para trabajar con: plantillas, bibliotecas y proyectos. Es mucho más fácil decir: npm upgrade fable-compiler y estará listo para funcionar (con suerte sin cambios importantes)

Dado que arreglaron la fijación de versiones de las herramientas locales, distribuir Fable 3 como una herramienta dotnet es probablemente el camino a seguir, como lo están haciendo todas las demás herramientas de F # (Paket, Fake, Fantomas, Femto, Snowflaqe). Mantener el compilador de fábulas como una distribución paralela probablemente resultará más confuso para los usuarios que tener un corte claro.

Preferiría que la gente se acostumbrara a llamar a Fable como una herramienta dotnet 😸 Pero ... entiendo que actualizar todos los tutoriales, proyectos y plantillas es una molestia (como lo ha sido en el pasado). Así que podríamos considerar lanzar una nueva versión principal de Fable-Loader que simplemente invoca la herramienta Fable dotnet. Los pasos para actualizar (cuando se lanzan las versiones estables) serían simplemente:

dotnet tool install fable
npm upgrade fable-loader

Probablemente también agregue *.fs.js a .gitignore. fable-compiler se puede desinstalar o no, simplemente no se invocará. ¿Cómo se vería eso? Y, ¿alguien se ofrecería voluntario para mantener el nuevo cargador de fábulas? 😉

Mantener el compilador de fábulas como una distribución paralela probablemente resultará más confuso para los usuarios que tener un corte claro.

Mantener la compatibilidad con versiones anteriores con los cambios mínimos requeridos es realmente importante y haría felices a muchas personas. En este momento, suena más como una degradación debido al nivel de indirección introducido (primero se ha llamado a fable, luego a webpack) y el webpack esperará que los archivos existan solo después de que Fable los compila, mientras que en este momento es totalmente _invisible_ y se parece mucho a cómo se integra TypeScript con proyectos existentes.

Me gusta la herramienta CLI para simplificar la construcción y ejecución de aplicaciones node.js en lugar de usar fable-splitter

Dado que arreglaron la fijación de versiones de las herramientas locales, la distribución de Fable 3 como una herramienta dotnet es probablemente el camino a seguir.

¿Quizás sea una idea hacer una encuesta (en twitter por ejemplo) para preguntar a los usuarios existentes qué preferirían?

Pasar la discusión al # 2195 ya que este problema se trata de los mapas de origen y puede resultar confuso para los colaboradores.

Sin mapas de origen, no habrá forma de integrarse con la depuración paso a paso en VSCode a través de launch.json , ¿es correcto?

Supongo que la mayoría de los usuarios de front-end preferirán usar un depurador que viaje en el tiempo de todos modos.

Todavía puede usar el depurador VSCode, pero los puntos de interrupción solo se pueden alcanzar en los archivos JS generados. Usé los mapas de origen con frecuencia tanto en VSCode como en Chrome (aunque a veces la alteración de nombres dificultaba la identificación de valores, algo que estamos tratando de mejorar en Nagareyama), pero no sé si muchos otros usuarios lo hicieron.

Todavía no he iniciado ningún código en esto, pero estoy atento a esto. Mi primera inclinación es hacer un puerto directo de mozilla / source-map asumiendo que esto es precisamente lo que se necesita, pero luego me pregunto si sería mejor optar por C # o F # para el puerto, preferiría hacerlo. escribirlo en F # yo mismo, pero hay algunos beneficios al elegir C #. De cualquier manera, la migración de la biblioteca proporcionaría una implementación nativa de .NET para trabajar con mapas de origen en general, lo que puede ser útil para el ecosistema .NET. Por ahora, he bifurcado el proyecto con la intención de darle una oportunidad a esta opción en mi limitado tiempo libre.

Otra opción que quizás se me acaba de ocurrir sería usar el soporte de WebAssembly para mozilla / source-map library para compilar en WebAssembly y luego incrustar el WASM en una biblioteca .NET usando Wasmtime . No estoy tan familiarizado con esta opción, pero si funciona y funciona de manera razonable, puede ser una forma más fácil de mantener la implementación sincronizada con la biblioteca de mapas de origen original en Javascript.

Otra opción que quizás se me acaba de ocurrir sería usar el soporte de WebAssembly para mozilla / source-map library para compilar en WebAssembly y luego incrustar el WASM en una biblioteca .NET usando Wasmtime . No estoy tan familiarizado con esta opción, pero si funciona y funciona de manera razonable, puede ser una forma más fácil de mantener la implementación sincronizada con la biblioteca de mapas de origen original en Javascript.

Casi parece que necesitamos un script de Java para el transpilador de F # ... 🤷

Con toda seriedad, una biblioteca de mapas fuente F # sería una buena idea.

https://github.com/delneg/source-map-sharp
Empecé a trabajar traduciendo https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js
allí, no es el mejor código en absoluto, pero intenté hacer una traducción directa

Esto es genial @delneg , ¡muchas gracias! Creo que una traducción directa funciona mejor incluso si no es idiomática de F # en caso de que necesitemos sincronizar las actualizaciones de la biblioteca original más tarde: +1:

He trabajado un poco (aquí https://github.com/delneg/source-map-sharp), pero es posible que necesite ayuda con las funciones "util.js" como util.join , util.relative que se utilizan en source-map-generator.js

Estoy casi seguro de que no necesitaremos util.getArg debido a la seguridad de tipo F #, y estoy casi seguro de que no necesitaremos util.toSetString porque es un truco para evitar errores relacionados con '__proto __'.

Por favor, dígame también si lo usaremos como CLI o ...

¡Gracias @delneg! Voy a echar un vistazo durante el fin de semana e intentaré PR esas funciones: +1: Sí, la biblioteca se utilizará desde Fable.Cli. Si lo publica como una biblioteca independiente, podemos hacer referencia a su paquete Nuget.

Hice la mayor parte de SourceMapNode, SourceMapGenerator y creé un README.md para mostrar el progreso actual.
Además, puede encontrar qué tipo de ayuda se necesita en un cajero automático.

De acuerdo con los documentos aquí https://github.com/mozilla/source-map#generating -a-source-map, lo que tenemos ahora es suficiente para generar mapas de origen ... (aunque no estoy del todo seguro de cómo Cajero automático)

¡Esto es fantástico @delneg! Lo intenté rápidamente y parece que funciona: +1: ahora intentaré habilitar la depuración.

Eso está bien, ¿puedes proponer los próximos pasos?
Es decir, publicar nuget o escribir pruebas o algo más (tal vez algo del README en el repositorio)
(PD, aunque nunca he publicado nuget, y probablemente debería hacerlo usando una cuenta de fábula)
PPS no es de extrañar que funcionó de inmediato, me he acostumbrado bastante a eso mientras uso F #

Los próximos pasos deberían ser probar que los mapas de origen realmente funcionan para la depuración y hacer el trabajo adicional en Fable (agregando la opción --sourceMap , guardándolo en un archivo`. Puedo hacer esto de mi lado. También te enviaré un PR para pulir un poco la API (como usar argumentos opcionales en lugar de opciones explícitas).

En este momento no tenemos una cuenta de Fable Nuget, estamos publicando los paquetes con nuestra cuenta personal y generalmente 2-3 propietarios por si acaso. Si crea una cuenta en nuget.org y genera un token, es fácil automatizar la publicación . Puedo hacer publicidad del guión para eso. También puedes agregarme como colaborador del paquete si quieres.

Ok, revisaré las publicaciones de nuget cuando tenga tiempo
Además, te agregué como colaborador al repositorio.
Si puedo, intentaré pulir un poco la API también e intentaré agregar algunas pruebas para SourceGenerator

Comencé a agregar más pruebas para SourceMapGenerator, revelaron algunos errores que se estaban escondiendo.
Algunos ahora están arreglados, pero antes parecía que todos debían arreglarse; de ​​lo contrario, es posible que las asignaciones no funcionen en algunos casos
Entonces, es un poco pronto para publicar nuget atm
Si alguien quiere ayudar, solo eche un vistazo a las pruebas fallidas ( dotnet test )

https://www.nuget.org/packages/source-map-sharp/
He publicado el paquete nuget, las pruebas para la generación de asignaciones reales relacionadas con SourceMapGenerator (función SerializeMapping) están hechas y los errores están corregidos, por lo que debería funcionar correctamente.
Continuaré con SourceNode y otras cosas, y sería genial si alguien1 pudiera ayudar con util.relative / util.join

¡Esto es genial @delneg! ¡Muchas gracias por esto! Poco a poco estoy volviendo al trabajo después de las vacaciones, así que intentaré impulsar una versión beta de Fable 3.1 con soporte de mapas de origen usando su paquete cuando sea posible: +1:

Creo que Fable en sí no necesita SourceNode, pero si prefiere agregarlo para completarlo, puede ayudar a otros consumidores de la biblioteca. Aproximadamente util.relative/join , también intentaré enviar un PR a su proyecto, pero dado que esto se ejecutará en .NET, supongo que debería poder usar System.IO.Path.GetRelativePath y System.IO.Path.Combine : https://docs.microsoft.com/en-us/dotnet/api/system.io.path?view=net-5.0

Desafortunadamente, GetRelativePath no está disponible para netstandard2.0 (consulte https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getrelativepath?view=net-5.0#applies -para)
La solución puede ser pasar a netstandard2.1 (aunque no sé si es bueno)
Con respecto a util.join , después de revisar todas las ocurrencias, creo que se usa solo en casos relacionados con consumer (que no haré en atm), por lo que en realidad no es tan necesario en este momento.

PD Con respecto al SourceNode, etc., creo que si estamos haciendo un puerto .net de sourcemap, hagámoslo implementando correctamente todas las cosas que hay, incluso si no se usa ahora, puede ser necesario en un año o dos

.Net Standard 2.1 dejaría las cosas relacionadas con Mono en el polvo (es decir, las cosas de Xamarin). Pero para el caso de uso de Fable, probablemente esté bien, ya que es una dependencia solo de desarrollo y el marco realmente no significa nada en tiempo de ejecución de todos modos.

Entonces, si la biblioteca solo se usará en Fable, 2.1 está bien, pero si desea la máxima compatibilidad con otras cosas .Net, 2.0 es más ideal para eso.

FWIW, alguien proporcionó una implementación simple en StackOverflow: https://stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

.Net Standard 2.1 dejaría las cosas relacionadas con Mono en el polvo (es decir, las cosas de Xamarin). Pero para el caso de uso de Fable, probablemente esté bien, ya que es una dependencia solo de desarrollo y el marco realmente no significa nada en tiempo de ejecución de todos modos.

Entonces, si la biblioteca solo se usará en Fable, 2.1 está bien, pero si desea la máxima compatibilidad con otras cosas .Net, 2.0 es más ideal para eso.

FWIW, alguien proporcionó una implementación simple en StackOverflow: stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

Creo que, por ahora, lo subiré a 2.1 y dejaré una nota en el archivo README para los posibles usuarios de netstandard2.0.
Si alguien necesita que funcione con 2.0, tendremos una solución alternativa de Stackoverflow.

Editar: subido 1.0.1 https://www.nuget.org/packages/source-map-sharp/1.0.1 con netstandard2.1

Otra opción sería excluir condicionalmente (con #if) las cosas que dependen de GetRelativePath a través de la orientación múltiple, para que todo lo demás esté disponible en .Net estándar 2.0.

Otra opción sería excluir condicionalmente (con #if) las cosas que dependen de GetRelativePath a través de la orientación múltiple, para que todo lo demás esté disponible en .Net estándar 2.0.

Parece una complicación excesiva para el problema de una URL relativa simple (solo cajero automático que requiere GetRelativePath)

Fable como herramienta dotnet es netcoreapp3.1 por lo que está bien apuntar a netstandard2.1, solo es posible que deba normalizar la ruta cuando se ejecuta en Windows como Path.GetRelativePath(path, pathTo).Replace('\\', '/') .

Si desea que la biblioteca apunte a netstandard2.0 para obtener la máxima compatibilidad, como señala @jwosty , en realidad tenemos nuestra propia implementación. No lo he tocado en un tiempo pero parece funcionar bien: https://github.com/fable-compiler/Fable/blob/ba509a94a50522794d3e60f27dd826bb5602eca1/src/Fable.Transforms/Global/Prelude.fs#L508 -L555

Además, Path.GetRelativePath no agrega un punto siempre delante de la ruta relativa:

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

El período probablemente sea necesario para las URL de sourcemaps, por lo que es posible que también deba hacer algo como en las líneas 545-548 del extracto anterior al normalizar la ruta.

Revisaré lo anterior y adaptaré las pruebas de JS (hay bastantes en test-util.js), probablemente usemos nuestra propia implementación.
Además, quedan un par de preguntas:
1) ¿Quizás deberíamos migrar la discusión a problemas de repositorios de mapas de fuentes definidos?
2) ¿Estamos planeando usar una compilación de WASM de algún tipo para este proyecto (hay alguna razón para hacerlo, porque no sé la razón del uso de WASM en el repositorio original del mapa de origen)?
3) ¿Se necesita algo más para que Fable comience a usar source-map-sharp, en todo caso (incluidos documentos, pruebas, API adicionales, etc.)

Editar: OK, eso fue fácil, ya se agregó el Util.getRelativePath personalizado, se agregaron pruebas y, después de ligeras modificaciones, se volvieron verdes.
¿Deberíamos volver a netstandard2.0 entonces y / o publicar 1.0.2 nuget?

¡Impresionante @delneg! 👏 🚀 👏

1. Sí, tiene sentido mover la discusión al repositorio de source-map-sharp: +1: Por favor, menciónenme cuando necesite mi entrada para que reciba la notificación.
2. No verifiqué el uso de WASM en el mapa de fuente original, pero supongo que lo usan en entornos que admiten WASM para acelerar los cálculos numéricos. No creo que debamos preocuparnos por eso en el puerto .NET.
3. Debería estar bien, simplemente no tuve mucho tiempo estos días, pero intentaré publicar una versión beta de 3.1 pronto con mapas de origen 💪 Puede seguir adelante y publicar 1.0.2, así que usaremos esto en la versión beta.

¡Fable 3.1 beta se publica con soporte de mapas fuente gracias al fantástico trabajo de @delneg ! : tada: https://twitter.com/FableCompiler/status/1347421291502997504

Fantástico - de un usuario de Fable: ¡muchas gracias por esto @delneg !

¡Increíble increíble increíble!

¡Impresionante @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.

Gracias por su apoyo.
Haré todo lo posible para mantener la nitidez del mapa de origen en el futuro, y me alegro de que funcione ahora.
1) Escribiré en los problemas del repositorio y, si alguien tiene alguna pregunta, etc., abra un problema en source-map-sharp
2) Sí, supongo que usaron WASM para mejorar el rendimiento.
Probé y obtuve la versión WASM de source-map-sharp funcionando, sin embargo, el estado de la compilación WASM en .net parece horrible y muy difícil de usar (se ha realizado algo de trabajo en el proyecto Uno.Platform.Bootstrap, pero al verlo el código fuente me decepcionó mucho)
En la medida en que source-map-sharp se mantiene como una aplicación .NET, si alguna vez necesitamos más rendimiento, siempre podemos mirar Spany otras cosas .NET para hacerlo más rápido
3) Publiqué 1.0.2 y vi que ya lo usaste, así que eso es todo.
Intentaré continuar publicando Nuget's en el futuro si encontramos algún error, etc. (y trataré de no cambiar la API)

Para cualquiera que aún no vea los mapas de origen después de aplicar las instrucciones de @alfonsogarciacaro , intente limpiar sus archivos de salida (incluidos todos los .fs.js ) y vuelva a ejecutar su compilación. Me tomó un tiempo darme cuenta de que simplemente reconstruir sin limpiar no funcionaba.

Aparte de eso, gracias a todos los involucrados por traer de vuelta esta gran característica 👍

¡Impresionante trabajo! Regresé hoy para ver si podía retomar este proyecto y para mi deleite ya está completo. Archivé el repositorio que había comenzado a crear para este esfuerzo y señalé el repositorio https://github.com/delneg/source-map-sharp por ahora. ¡De nuevo gran trabajo!