Fable: Kembalikan dukungan peta sumber

Akankah Fable 3 tidak lagi didistribusikan melalui paket fable-compiler (digunakan bersama fable-loader )? Saya mengerti bahwa aplikasi Fable murni memiliki pengalaman pengguna yang lebih baik daripada pembagi dongeng untuk membuat aplikasi node.js tetapi menghapus distribusi npm akan menjadi perubahan besar di mana-mana dan sejujurnya sedikit menyusahkan di belakang untuk bekerja dengan: templat, perpustakaan dan proyek. Jauh lebih mudah untuk mengatakan: npm upgrade fable-compiler dan itu akan siap untuk digunakan (semoga tanpa merusak perubahan)

Karena mereka memperbaiki penyematan versi alat lokal, mendistribusikan Fable 3 sebagai alat dotnet kemungkinan besar merupakan cara yang tepat, seperti yang dilakukan semua alat F# lainnya (Paket, Fake, Fantomas, Femto, Snowflaqe). Menjaga fable-compiler sebagai distribusi paralel mungkin akan lebih membingungkan pengguna daripada memiliki potongan yang jelas.

Saya lebih suka jika orang terbiasa menyebut Fable sebagai alat dotnet Tapi... Saya mengerti bahwa memperbarui semua tutorial, proyek, templat itu merepotkan (seperti yang sudah-sudah). Jadi kami dapat mempertimbangkan untuk merilis versi utama fable-loader baru yang hanya menggunakan alat Fable dotnet. Langkah-langkah untuk memutakhirkan (ketika versi stabil dirilis) adalah:

dotnet tool install fable
npm upgrade fable-loader

Mungkin juga menambahkan *.fs.js ke .gitignore. fable-compiler dapat dihapus atau tidak, itu tidak akan dipanggil. Bagaimana itu terlihat? Dan, akankah seseorang secara sukarela memelihara pemuat dongeng yang baru? 😉

Menjaga fable-compiler sebagai distribusi paralel mungkin akan lebih membingungkan pengguna daripada memiliki potongan yang jelas.

Menjaga kompatibilitas mundur dengan sedikit perubahan yang diperlukan sangat penting dan akan membuat banyak orang senang. Saat ini, kedengarannya lebih seperti penurunan versi karena tingkat tipuan yang diperkenalkan (fable telah dipanggil terlebih dahulu, kemudian webpack) dan webpack akan mengharapkan file hanya ada setelah Fable mengompilasinya sedangkan saat ini benar-benar _tidak terlihat_ dan terlihat sangat mirip bagaimana TypeScript terintegrasi dengan proyek yang ada.

Saya suka alat CLI untuk menyederhanakan pembuatan dan menjalankan aplikasi node.js daripada menggunakan pemisah dongeng

Karena mereka memperbaiki penyematan versi alat lokal, mendistribusikan Fable 3 sebagai alat dotnet kemungkinan adalah cara yang tepat

Mungkin ide untuk membuat polling (di twitter misalnya) untuk menanyakan pengguna yang sudah ada apa yang mereka inginkan?

Memindahkan diskusi ke #2195 karena masalah ini tentang peta sumber dan dapat membingungkan kontributor.

Tanpa peta sumber tidak akan ada cara untuk berintegrasi dengan debugging langkah demi langkah di VSCode melalui launch.json , apakah itu benar?

Saya kira sebagian besar pengguna front-end akan lebih suka menggunakan debugger perjalanan waktu.

Anda masih dapat menggunakan debugger VSCode tetapi breakpoints hanya dapat mengenai file JS yang dihasilkan. Saya memang sering menggunakan peta sumber baik di VSCode dan Chrome (walaupun terkadang kesalahan nama membuat sulit untuk mengidentifikasi nilai, sesuatu yang kami coba tingkatkan di Nagareyama), tetapi saya tidak tahu apakah banyak pengguna lain yang melakukannya.

Saya belum memulai kode apa pun tentang ini, tetapi saya mengawasi ini. Kecenderungan pertama saya adalah melakukan port langsung mozilla/source-map dengan asumsi bahwa inilah yang dibutuhkan tetapi kemudian saya bertanya-tanya apakah kita akan lebih baik menggunakan C# atau F# untuk port tersebut, saya lebih suka menulisnya dalam F# sendiri tetapi ada beberapa manfaat dalam memilih C#. Either way port perpustakaan akan memberikan implementasi .NET asli untuk bekerja dengan peta sumber secara umum yang mungkin menjadi hal yang berguna untuk ekosistem .NET. Untuk saat ini saya telah melakukan fork pada proyek dengan maksud untuk mencoba opsi ini di waktu luang saya yang terbatas.

Pilihan lain yang mungkin baru saja terpikir oleh saya adalah menggunakan dukungan WebAssembly untuk perpustakaan mozilla/source-map untuk dikompilasi ke WebAssembly dan kemudian menyematkan WASM ke perpustakaan .NET menggunakan Wasmtime . Saya tidak begitu akrab dengan opsi ini tetapi jika berfungsi dan berkinerja wajar, ini mungkin cara yang lebih mudah untuk menjaga implementasi tetap sinkron dengan pustaka peta sumber asli di Javascript.

Pilihan lain yang mungkin baru saja terpikir oleh saya adalah menggunakan dukungan WebAssembly untuk perpustakaan mozilla/source-map untuk dikompilasi ke WebAssembly dan kemudian menyematkan WASM ke perpustakaan .NET menggunakan Wasmtime . Saya tidak begitu akrab dengan opsi ini tetapi jika berfungsi dan berkinerja wajar, ini mungkin cara yang lebih mudah untuk menjaga implementasi tetap sinkron dengan pustaka peta sumber asli di Javascript.

Hampir terdengar seperti kita membutuhkan Java-script untuk F# transpiler...

Dalam semua keseriusan, perpustakaan peta sumber F# akan menjadi ide yang bagus.

https://github.com/delneg/source-map-sharp
Memulai beberapa pekerjaan menerjemahkan https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js
di sana, bukan kode terbaik sama sekali tetapi saya mencoba melakukan terjemahan langsung

Ini bagus @delneg , terima kasih banyak! Saya pikir terjemahan langsung berfungsi paling baik meskipun itu bukan idiomatik F# jika kita perlu menyinkronkan pembaruan perpustakaan asli nanti :+1:

Saya telah melakukan beberapa pekerjaan (di sini https://github.com/delneg/source-map-sharp), tetapi saya mungkin memerlukan bantuan dengan fungsi "util.js" seperti util.join , util.relative yang digunakan dalam source-map-generator.js

Saya hampir yakin kita tidak memerlukan util.getArg karena keamanan tipe F#, dan saya hampir yakin kita tidak memerlukan util.toSetString karena ini adalah peretasan untuk menghindari bug terkait '__proto__'.

Tolong beri tahu saya juga apakah kami akan menggunakannya sebagai CLI atau ... ?

Terima kasih @delneg! Saya akan melihat selama akhir pekan dan saya akan mencoba untuk PR fungsi-fungsi itu :+1: Ya, perpustakaan akan digunakan dari Fable.Cli. Jika Anda menerbitkannya sebagai perpustakaan independen, kami hanya dapat mereferensikan paket Nuget Anda.

Saya telah melakukan sebagian besar SourceMapNode, SourceMapGenerator, dan membuat README.md untuk menunjukkan kemajuan saat ini.
Juga, Anda dapat menemukan bantuan seperti apa yang dibutuhkan atm.

Menurut dokumen di sini https://github.com/mozilla/source-map#generating -a-source-map , apa yang kami miliki sekarang sudah cukup untuk menghasilkan peta sumber ... (walaupun, saya tidak sepenuhnya yakin caranya ATM)

Ini luar biasa @delneg! Saya mencobanya sebentar dan sepertinya berhasil :+1: Sekarang saya akan mencoba mengaktifkan debugging.

Itu bagus, bisakah Anda mengusulkan langkah selanjutnya?
Yaitu menerbitkan nuget atau menulis tes atau yang lainnya (mungkin sesuatu dari README di repo)
(PS meskipun saya belum pernah melakukan penerbitan nuget, dan mungkin harus dilakukan menggunakan akun fabel)
PPS tidak heran itu langsung berfungsi, saya sudah cukup terbiasa dengan itu saat menggunakan F#

Langkah selanjutnya harus menguji bahwa peta sumber benar-benar berfungsi untuk debugging dan melakukan pekerjaan ekstra di Fable (menambahkan opsi --sourceMap , menyimpannya ke file`. Saya dapat melakukan ini di pihak saya. Saya juga akan mengirimkan PR kepada Anda untuk memoles sedikit API (seperti menggunakan argumen opsional alih-alih opsi eksplisit).

Saat ini kami tidak memiliki akun Fable Nuget, kami menerbitkan paket dengan akun pribadi kami dan biasanya 2-3 pemilik untuk berjaga-jaga. Jika Anda membuat akun di nuget.org dan membuat token, mudah untuk mengotomatiskan penerbitan . Saya bisa PR skrip untuk itu. Anda juga dapat menambahkan saya sebagai kolaborator paket jika Anda mau.

Oke, saya akan memeriksa hal-hal penerbitan nuget ketika saya punya waktu
Juga, saya telah menambahkan Anda sebagai kolaborator ke repo
Jika saya bisa, saya akan mencoba memoles API sedikit juga, dan mencoba menambahkan beberapa tes untuk SourceGenerator

Saya sudah mulai menambahkan lebih banyak tes untuk SourceMapGenerator, mereka mengungkapkan beberapa bug yang bersembunyi.
Beberapa sekarang sudah diperbaiki, tetapi sebelumnya sepertinya semuanya perlu diperbaiki - jika tidak, pemetaan mungkin tidak berfungsi dalam beberapa kasus
Jadi, agak terlalu dini untuk menerbitkan nuget atm
Jika ada yang ingin membantu - lihat saja tes yang gagal ( dotnet test )

https://www.nuget.org/packages/source-map-sharp/
Saya telah menerbitkan paket nuget, tes untuk pembuatan pemetaan aktual terkait SourceMapGenerator (fungsi SerializeMapping) selesai & bug diperbaiki, jadi itu harus berfungsi dengan baik.
Saya akan melanjutkan SourceNode & hal-hal lain, dan akan sangat bagus jika some1 bisa membantu dengan util.relative / util.join

Ini bagus @delneg! Terima kasih banyak untuk ini! Saya perlahan-lahan kembali bekerja setelah liburan jadi saya akan mencoba untuk mendorong rilis beta Fable 3.1 dengan dukungan peta sumber menggunakan paket Anda jika memungkinkan :+1:

Saya pikir Fable sendiri tidak membutuhkan SourceNode tetapi jika Anda lebih suka menambahkannya untuk kelengkapan, itu dapat membantu konsumen perpustakaan lainnya. Tentang util.relative/join , saya juga akan mencoba mengirim PR ke proyek Anda, tetapi mengingat ini akan berjalan di .NET, saya kira Anda harus dapat menggunakan System.IO.Path.GetRelativePath dan System.IO.Path.Combine : https://docs.microsoft.com/en-us/dotnet/api/system.io.path?view=net-5.0

Sayangnya, GetRelativePath tidak tersedia untuk netstandard2.0 (lihat https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getrelativepath?view=net-5.0#applies -ke)
Solusinya bisa dengan menabrak netstandard2.1 (saya tidak tahu apakah itu bagus)
Mengenai util.join - setelah melihat semua kejadian, saya yakin ini hanya digunakan dalam consumer -kasus terkait (yang tidak akan saya lakukan di atm), jadi sebenarnya itu tidak diperlukan saat ini.

PS Mengenai SourceNode dll - saya pikir jika kita melakukan port .net dari sourcemap, mari kita lakukan dengan benar menerapkan semua hal yang ada, bahkan jika itu tidak digunakan sekarang mungkin diperlukan dalam satu atau dua tahun

.Net Standard 2.1 akan meninggalkan hal-hal yang berhubungan dengan Mono dalam debu (yaitu hal-hal Xamarin). Tetapi untuk kasus penggunaan Fable itu mungkin baik-baik saja karena ini hanya ketergantungan pengembangan dan kerangka kerja tidak berarti apa-apa saat runtime.

Jadi jika perpustakaan hanya akan digunakan di Fable, 2.1 baik-baik saja, tetapi jika Anda ingin kompatibilitas maksimum dengan hal-hal .Net lainnya, 2.0 lebih ideal untuk itu.

FWIW, seseorang memberikan implementasi sederhana di StackOverflow: https://stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

.Net Standard 2.1 akan meninggalkan hal-hal yang berhubungan dengan Mono dalam debu (yaitu hal-hal Xamarin). Tetapi untuk kasus penggunaan Fable itu mungkin baik-baik saja karena ini hanya ketergantungan pengembangan dan kerangka kerja tidak berarti apa-apa saat runtime.

Jadi jika perpustakaan hanya akan digunakan di Fable, 2.1 baik-baik saja, tetapi jika Anda ingin kompatibilitas maksimum dengan hal-hal .Net lainnya, 2.0 lebih ideal untuk itu.

FWIW, seseorang memberikan implementasi sederhana di StackOverflow: stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

Saya pikir untuk saat ini saya akan mengubahnya menjadi 2.1, dan meninggalkan catatan di README untuk calon pengguna netstandard2.0.
Jika ada yang membutuhkannya untuk bekerja di bawah 2.0, kami akan memiliki solusi cadangan dari Stackoverflow.

Sunting: diunggah 1.0.1 https://www.nuget.org/packages/source-map-sharp/1.0.1 dengan netstandard2.1

Pilihan lain adalah mengecualikan secara kondisional (dengan #if) hal-hal yang bergantung pada GetRelativePath melalui multitargeting, sehingga segala sesuatu yang lain akan tersedia di .Net standar 2.0.

Pilihan lain adalah mengecualikan secara kondisional (dengan #if) hal-hal yang bergantung pada GetRelativePath melalui multitargeting, sehingga segala sesuatu yang lain akan tersedia di .Net standar 2.0.

Sepertinya rumit untuk masalah URL relatif sederhana (hanya atm yang membutuhkan GetRelativePath )

Fabel sebagai alat dotnet adalah netcoreapp3.1 jadi tidak masalah untuk menargetkan netstandard2.1, hanya saja Anda mungkin perlu menormalkan jalur saat dijalankan di Windows seperti Path.GetRelativePath(path, pathTo).Replace('\\', '/') .

Jika Anda ingin perpustakaan menargetkan netstandard2.0 untuk kompatibilitas maksimum seperti yang ditunjukkan @jwosty , kami sebenarnya memiliki implementasi kami sendiri. Saya belum menyentuhnya dalam beberapa saat tetapi tampaknya berfungsi dengan baik: https://github.com/fable-compiler/Fable/blob/ba509a94a50522794d3e60f27dd826bb5602eca1/src/Fable.Transforms/Global/Prelude.fs#L508 -L555

Juga Path.GetRelativePath tidak selalu menambahkan titik di depan jalur relatif:

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

Titik mungkin diperlukan untuk url peta sumber, jadi Anda mungkin juga perlu melakukan sesuatu seperti pada baris 545-548 kutipan di atas saat menormalkan jalur.

Saya akan memeriksa hal-hal di atas & mengadaptasi tes dari JS (ada cukup banyak di test-util.js), mungkin akan menggunakan implementasi kami sendiri.
Juga, beberapa pertanyaan yang tersisa:
1) Mungkin kita harus memigrasikan diskusi ke masalah repositori source-map-sharp?
2) Apakah kami berencana menggunakan kompilasi WASM untuk proyek ini (apakah ada alasan untuk melakukan itu, karena saya tidak tahu alasan penggunaan WASM di repo atm peta sumber asli)?
3) Apakah ada hal lain yang diperlukan agar Fable mulai menggunakan source-map-sharp, jika ada (termasuk dokumen, tes, API tambahan, dll.)?

Sunting: OK, itu mudah, sudah menambahkan Util.getRelativePath khusus, menambahkan tes dan setelah sedikit modifikasi mereka menjadi hijau.
Haruskah kita kembali ke netstandard2.0 lalu dan/atau menerbitkan 1.0.2 nuget?

Luar biasa @delneg! 👏 🚀 👏

1. Ya masuk akal untuk memindahkan diskusi ke repositori source-map-sharp :+1: Tolong sebutkan saya ketika Anda membutuhkan masukan saya sehingga saya mendapatkan pemberitahuan.
2. Tidak memeriksa penggunaan WASM di peta sumber asli, tetapi saya berasumsi mereka menggunakannya di lingkungan yang mendukung WASM untuk mempercepat perhitungan numerik. Saya rasa kita tidak perlu mengkhawatirkannya di port .NET.
3. Seharusnya baik-baik saja, saya hanya tidak punya banyak waktu akhir-akhir ini, tetapi saya akan mencoba untuk segera menerbitkan rilis beta 3.1 dengan peta sumber Anda dapat melanjutkan dan menerbitkan 1.0.2 jadi kami menggunakan ini dalam versi beta.

Fabel 3.1 beta diterbitkan dengan dukungan peta sumber berkat kerja fantastis @delneg ! :tada: https://twitter.com/FableCompiler/status/1347421291502997504

Fantastis - dari pengguna Fabel: terima kasih banyak untuk @delneg ini!

Luar biasa luar biasa luar biasa!

Luar biasa @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.

Terima kasih atas dukunganmu.
Saya akan mencoba yang terbaik untuk mempertahankan source-map-sharp di masa mendatang, dan saya senang itu berhasil sekarang.
1) Saya akan menulis masalah repo, dan jika ada yang memiliki pertanyaan, dll. - silakan buka masalah di source-map-sharp
2) Ya, saya kira mereka memang menggunakan WASM untuk meningkatkan kinerja.
Saya memang mencoba dan mendapatkan versi WASM dari source-map-sharp yang berfungsi, namun keadaan kompilasi WASM di .net tampaknya buruk dan sangat sulit digunakan (beberapa pekerjaan dilakukan di proyek Uno.Platform.Bootstrap, tetapi melihat itu kode sumber sangat mengecewakan saya)
Sejauh source-map-sharp menyimpan aplikasi .NET, jika kita membutuhkan lebih banyak kinerja, kita selalu dapat melihat Spandan hal-hal .NET lainnya untuk membuatnya lebih cepat
3) Saya menerbitkan 1.0.2 dan saya melihat bahwa Anda telah menggunakannya, jadi itu saja.
Saya akan mencoba untuk terus menerbitkan Nuget di masa mendatang jika kami menemukan bug, dll. (dan cobalah untuk tidak mengubah API)

Bagi siapa pun yang masih tidak melihat peta sumber setelah menerapkan instruksi dari @alfonsogarciacaro , coba bersihkan file keluaran Anda (termasuk semua yang .fs.js ) dan jalankan kembali build Anda. Butuh beberapa saat bagi saya untuk mengetahui hal ini karena hanya membangun kembali tanpa pembersihan tidak berhasil.

Selain itu, terima kasih kepada semua orang yang terlibat karena telah menghadirkan kembali fitur hebat ini 👍

Pekerjaan yang luar biasa! Saya kembali hari ini untuk melihat apakah saya bisa mengambil proyek ini dan saya senang itu sudah selesai. Saya telah mengarsipkan repo yang saya mulai perancah untuk upaya ini dan menunjuk ke https://github.com/delneg/source-map-sharp repo untuk saat ini. Sekali lagi pekerjaan yang bagus!