Fable: Traga de volta o suporte do mapa de origem

O Fable 3 não será mais distribuído por meio do pacote fable-compiler (usado junto com fable-loader )? 😱 Eu entendo que o aplicativo Fable puro tem uma experiência de usuário melhor do que o divisor de fábulas para fazer aplicativos node.js, mas remover a distribuição npm seria uma grande mudança em todos os lugares e, honestamente, seria um pouco chato trabalhar com: modelos, bibliotecas e projetos. É muuuito mais fácil dizer: npm upgrade fable-compiler e ele estará pronto para uso (espero que sem alterar as alterações)

Como eles consertaram a fixação de versão das ferramentas locais, distribuir o Fable 3 como uma ferramenta dotnet é provavelmente o caminho a percorrer, como todas as outras ferramentas F # estão fazendo (Paket, Fake, Fantomas, Femto, Snowflaqe). Manter o compilador de fábulas como uma distribuição paralela provavelmente será mais confuso para os usuários do que ter um corte claro.

Eu preferiria que as pessoas se acostumassem a chamar o Fable como uma ferramenta dotnet 😸 Mas ... eu entendo que atualizar todos os tutoriais, projetos, modelos é uma dor (como tem sido no passado). Portanto, poderíamos considerar o lançamento de uma nova versão principal do carregador de fábulas que apenas invoca a ferramenta Fable dotnet. As etapas para atualizar (quando as versões estáveis ​​são lançadas) seriam apenas:

dotnet tool install fable
npm upgrade fable-loader

Provavelmente também adicionando *.fs.js a .gitignore. fable-compiler pode ser desinstalado ou não, apenas não será invocado. Como ficaria isso? E alguém se voluntariaria para manter o novo carregador de fábulas? 😉

Manter o compilador de fábulas como uma distribuição paralela provavelmente será mais confuso para os usuários do que ter um corte claro.

Manter a compatibilidade com versões anteriores com o mínimo de alterações necessárias é muito importante e faria muitas pessoas felizes. No momento, parece mais um rebaixamento por causa do nível de indireção introduzido (fable foi chamada primeiro, depois webpack) e webpack espera que os arquivos existam apenas após Fable compilá-los, enquanto que agora é totalmente _invisível_ e se parece muito com como o TypeScript é integrado aos projetos existentes.

Eu gosto da ferramenta CLI para simplificar a construção e execução de aplicativos node.js em vez de usar o divisor de fábula

Como eles corrigiram a fixação de versão de ferramentas locais, distribuir o Fable 3 como uma ferramenta dotnet é provavelmente o caminho a percorrer

Talvez seja uma ideia fazer uma enquete (no Twitter, por exemplo) para perguntar aos usuários existentes o que eles preferem?

Movendo a discussão para # 2195, pois este problema é sobre os mapas de origem e pode ser confuso para os contribuidores.

Sem os mapas de origem, não haverá como integrar a depuração passo a passo no VSCode por meio de launch.json , correto?

Estou supondo que a maioria dos usuários front-end preferirá usar um depurador de viagem no tempo de qualquer maneira.

Você ainda pode usar o depurador VSCode, mas os pontos de interrupção só podem ser atingidos nos arquivos JS gerados. Eu usei os mapas de origem com frequência tanto no VSCode quanto no Chrome (embora às vezes a mutilação de nomes dificultasse a identificação de valores, algo que estamos tentando melhorar em Nagareyama), mas não sei se muitos outros usuários o fizeram.

Ainda não iniciei nenhum código nisso, mas estou de olho nisso. Minha primeira inclinação é fazer uma porta direta de mozilla / source-map presumindo que isso é precisamente o que é necessário, mas então estou me perguntando se seria melhor ir com C # ou F # para a porta, eu prefiro escrevê-lo em F #, mas há alguns benefícios em escolher C #. De qualquer forma, portar a biblioteca forneceria uma implementação nativa do .NET para trabalhar com mapas de origem em geral, o que pode ser útil para o ecossistema .NET. Por enquanto, bifurquei o projeto com a intenção de dar uma chance a essa opção em meu tempo livre limitado.

Outra opção que talvez me ocorreu seria usar o suporte WebAssembly para a biblioteca mozilla / source-map para compilar para WebAssembly e, em seguida, incorporar o WASM em uma biblioteca .NET usando Wasmtime . Não estou familiarizado com esta opção, mas se funcionar e executar razoavelmente, pode ser uma maneira mais fácil de manter a implementação em sincronia com a biblioteca de mapas de origem original em Javascript.

Outra opção que talvez me ocorreu seria usar o suporte WebAssembly para a biblioteca mozilla / source-map para compilar para WebAssembly e, em seguida, incorporar o WASM em uma biblioteca .NET usando Wasmtime . Não estou familiarizado com esta opção, mas se funcionar e executar razoavelmente, pode ser uma maneira mais fácil de manter a implementação em sincronia com a biblioteca de mapas de origem original em Javascript.

Quase parece que precisamos de um script Java para o transpilador F # ... 🤷

Com toda a seriedade, uma biblioteca de mapas de origem F # seria uma boa ideia.

https://github.com/delneg/source-map-sharp
Começou a traduzir https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js
ali, não é o melhor código, mas tentei fazer uma tradução direta

Isso é ótimo @delneg , muito obrigado! Acho que uma tradução direta funciona melhor mesmo que não seja idiomática em F #, caso precisemos sincronizar as atualizações da biblioteca original mais tarde: +1:

Fiz algum trabalho (aqui https://github.com/delneg/source-map-sharp), mas posso precisar de ajuda com as funções "util.js", como util.join , util.relative que são usados ​​em source-map-generator.js

Tenho quase certeza de que não precisaremos de util.getArg por causa da segurança do tipo F # e tenho quase certeza de que não precisaremos de util.toSetString porque é um hack para evitar bugs relacionados a '__proto __'-.

Diga-me também se usaremos isso como CLI ou ...?

Obrigado @delneg! Vou dar uma olhada no fim de semana e vou tentar PR essas funções: +1: Sim, a biblioteca será usada do Fable.Cli. Se você publicá-lo como uma biblioteca independente, podemos apenas fazer referência ao seu pacote Nuget.

Eu fiz a maior parte de SourceMapNode, SourceMapGenerator e criei um README.md para mostrar o progresso atual.
Além disso, você pode descobrir que tipo de ajuda é necessária atm.

De acordo com os documentos aqui https://github.com/mozilla/source-map#generating -a-source-map, o que temos agora é suficiente para gerar mapas de origem ... (embora, não tenho certeza de como atm)

Isso é fantástico @delneg! Eu tentei rapidamente e parece estar funcionando: +1: agora vou tentar habilitar a depuração.

Isso é bom, você pode propor os próximos passos?
Ou seja, publicar nuget ou escrever testes ou algo mais (talvez algo do README no repositório)
(PS, embora eu nunca tenha publicado nuget e provavelmente deva ser feito usando a conta de fábula)
PPS: não é à toa que funcionou imediatamente, estou bastante acostumado com isso enquanto uso o F #

Os próximos passos devem ser testar se os mapas de origem realmente funcionam para depurar e fazer o trabalho extra no Fable (adicionando a opção --sourceMap , salvando-a em um arquivo. Posso fazer isso do meu lado. Também enviarei um PR para polir um pouco a API (como usar argumentos opcionais em vez de opções explícitas).

No momento, não temos uma conta Fable Nuget, estamos publicando os pacotes com nossa conta pessoal e geralmente 2-3 proprietários, apenas para garantir. Se você criar uma conta em nuget.org e gerar um token, é fácil automatizar a publicação . Posso fazer a RP do roteiro para isso. Você também pode me adicionar como colaborador do pacote, se quiser.

Ok, vou verificar o material de publicação do nuget quando tiver tempo
Além disso, adicionei você como colaborador do repo
Se for possível, tentarei aperfeiçoar um pouco a API também e tentarei adicionar alguns testes para SourceGenerator

Comecei a adicionar mais testes para SourceMapGenerator, eles revelaram alguns bugs que estavam se escondendo.
Alguns agora estão corrigidos, mas antes parece que todos precisam ser corrigidos - caso contrário, os mapeamentos podem não funcionar em alguns casos
Então, é um pouco cedo para publicar o nuget atm
Se alguém quiser ajudar - basta dar uma olhada nos testes que falharam ( dotnet test )

https://www.nuget.org/packages/source-map-sharp/
Publiquei o pacote nuget, testes para geração de mapeamentos reais relacionados ao SourceMapGenerator (função SerializeMapping) foram feitos e os bugs foram corrigidos, então deve funcionar corretamente.
Vou continuar no SourceNode e outras coisas, e seria ótimo se alguém1 pudesse ajudar com util.relative / util.join

Isso é ótimo @delneg! Muito obrigado por isso! Estou voltando lentamente ao trabalho após as férias, então tentarei lançar uma versão beta do Fable 3.1 com suporte a mapa de origem usando seu pacote, quando possível: +1:

Acho que o próprio Fable não precisa do SourceNode, mas se você preferir adicioná-lo para ser completo, ele pode ajudar outros consumidores da biblioteca. Sobre util.relative/join , também tentarei enviar um PR para o seu projeto, mas como ele será executado em .NET, acho que você deve conseguir usar System.IO.Path.GetRelativePath e System.IO.Path.Combine : https://docs.microsoft.com/en-us/dotnet/api/system.io.path?view=net-5.0

Infelizmente, GetRelativePath não está disponível para netstandard2.0 (consulte https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getrelativepath?view=net-5.0#applies -para)
A solução pode ser atingir o netstandard2.1 (não sei se é um bom, no entanto)
Com relação a util.join - depois de examinar todas as ocorrências, acredito que seja usado apenas em casos relacionados a consumer (que não estarei fazendo atm), então, na verdade, não é tão necessário agora.

PS Em relação ao SourceNode etc. - acho que se estivermos fazendo uma porta .net do sourcemap, vamos fazê-lo implementando corretamente todas as coisas que existem, mesmo que não seja usado agora, pode ser necessário em um ou dois anos

.Net Standard 2.1 deixaria coisas relacionadas ao Mono no pó (isto é, coisas Xamarin). Mas, para o caso de uso do Fable, provavelmente não há problema, pois é uma dependência apenas de desenvolvimento e a estrutura não significa nada em tempo de execução de qualquer maneira.

Então, se a biblioteca vai ser usada apenas no Fable, 2.1 é bom, mas se você quer compatibilidade máxima com outras coisas .Net, 2.0 é mais ideal para isso.

FWIW, alguém forneceu uma implementação simples dele no StackOverflow: https://stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

.Net Standard 2.1 deixaria coisas relacionadas ao Mono no pó (isto é, coisas Xamarin). Mas, para o caso de uso do Fable, provavelmente não há problema, pois é uma dependência apenas de desenvolvimento e a estrutura não significa nada em tempo de execução de qualquer maneira.

Então, se a biblioteca vai ser usada apenas no Fable, 2.1 é bom, mas se você quer compatibilidade máxima com outras coisas .Net, 2.0 é mais ideal para isso.

FWIW, alguém forneceu uma implementação simples dele no StackOverflow: stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

Acho que por agora vou aumentar para 2.1 então, e deixar uma nota no README para usuários potenciais do netstandard2.0.
Se alguém precisar que funcione em 2.0, teremos uma solução alternativa de Stackoverflow.

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

Outra opção seria excluir condicionalmente (com #if) as coisas que dependem de GetRelativePath via multitargeting, de modo que todo o resto esteja disponível no .Net padrão 2.0.

Outra opção seria excluir condicionalmente (com #if) as coisas que dependem de GetRelativePath via multitargeting, de modo que todo o resto esteja disponível no .Net padrão 2.0.

Parece uma complicação excessiva para um problema de URL relativo simples (apenas atm que requer GetRelativePath)

Fable como uma ferramenta dotnet é netcoreapp3.1, portanto, não há problema em definir como netstandard2.1, apenas você pode precisar normalizar o caminho quando executado no Windows como Path.GetRelativePath(path, pathTo).Replace('\\', '/') .

Se você quiser que a biblioteca tenha como alvo o netstandard2.0 para compatibilidade máxima, como @jwosty aponta, na verdade temos nossa própria implementação. Não toquei nele há algum tempo, mas parece funcionar bem: https://github.com/fable-compiler/Fable/blob/ba509a94a50522794d3e60f27dd826bb5602eca1/src/Fable.Transforms/Global/Prelude.fs#L508 -L555

Além disso, Path.GetRelativePath não adiciona um ponto final sempre na frente do caminho relativo:

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

O ponto provavelmente é necessário para urls de mapas de origem, então você também pode precisar fazer algo como nas linhas 545-548 do trecho acima ao normalizar o caminho.

Vou verificar o material acima e adaptar os testes do JS (há muitos em test-util.js), provavelmente usarei nossa própria implementação.
Além disso, restam algumas perguntas:
1) Talvez devêssemos migrar a discussão para questões específicas do repositório do mapa de origem?
2) Estamos planejando usar a compilação WASM de algum tipo para este projeto (há uma razão para fazer isso, porque eu não sei a razão do uso do WASM no repositório de mapa de origem original)?
3) Há mais alguma coisa necessária para o Fable começar a usar o mapa de origem nítido, se houver alguma coisa (incluindo documentos, testes, APIs adicionais etc.)

Edit: OK, isso foi fácil, já adicionei o Util.getRelativePath customizado, adicionei testes e após pequenas modificações eles ficaram verdes.
Devemos reverter para netstandard2.0 e / ou publicar o nuget 1.0.2?

Incrível @delneg! 👏 🚀 👏

1. Sim, faz sentido mover a discussão para o repositório de mapa de origem nítido: +1: Por favor, me mencione quando precisar de minha entrada para que eu receba a notificação.
2. Não verifiquei o uso de WASM no mapa de origem original, mas suponho que eles o usam em ambientes que suportam WASM para acelerar cálculos numéricos. Não acho que precisamos nos preocupar com isso na porta .NET.
3. Deve ficar tudo bem, eu simplesmente não tive muito tempo hoje em dia, mas vou tentar publicar uma versão beta do 3.1 em breve com mapas de origem 💪 Você pode ir em frente e publicar o 1.0.2 para usarmos no beta.

Fable 3.1 beta é publicado com suporte a mapas de origem graças ao trabalho fantástico da @delneg ! : tada: https://twitter.com/FableCompiler/status/1347421291502997504

Fantástico - de um usuário do Fable: muito obrigado por este @delneg !

Incrível incrível incrível!

Incrível @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.

Obrigado por seu apoio.
Vou tentar o meu melhor para manter o mapa de origem nítido no futuro, e estou feliz que funcione agora.
1) Vou escrever os problemas do repo então, e se alguém tiver alguma dúvida, etc. - abra um problema no mapa de origem nítido
2) Sim, suponho que eles usaram WASM para melhorar o desempenho.
Eu tentei e consegui a versão WASM do source-map-sharp funcionando, no entanto, atm o estado da compilação WASM em .net parece horrível e muito difícil de usar (algum trabalho é feito no projeto Uno.Platform.Bootstrap, mas olhando para ele é o código-fonte me decepcionou muito)
Na medida em que o mapa de origem nítido é mantido em um aplicativo .NET, se precisarmos de mais desempenho, podemos sempre olhar para Spane outras coisas .NET para torná-lo mais rápido
3) Eu publiquei 1.0.2 e vi que você já usou, então é isso.
Tentarei continuar publicando Nuget no futuro se encontrarmos algum bug, etc. (e tentarei não alterar a API)

Para quem ainda não consegue ver os mapas de origem após aplicar as instruções de @alfonsogarciacaro , tente limpar seus arquivos de saída (incluindo todos os .fs.js uns) e execute sua construção novamente. Levei um tempo para descobrir isso, pois simplesmente reconstruir sem limpar não funcionava.

Além disso, obrigado a todos os envolvidos por trazerem de volta esse ótimo recurso 👍

Otimo trabalho! Voltei hoje para ver se poderia retomar este projeto e para minha alegria ele já está concluído. Arquivei o repositório que comecei a criar para esse esforço e apontei para o repositório https://github.com/delneg/source-map-sharp por enquanto. Mais uma vez, ótimo trabalho!