Fable: Bundling/server dev otomatis?

Dibuat pada 1 Apr 2021  ·  3Komentar  ·  Sumber: fable-compiler/Fable

Sejauh ini, Fable telah mencoba menjadi jembatan antara ekosistem F# dan JS. Dan dengan demikian, ia tidak mencoba melakukan terlalu banyak dan sebaliknya membiarkan pengguna memilih alat JS mereka untuk dibundel, men-debug frontend, dll... Namun, karena Fable 3 pindah ke alat dotnet "murni" dan dengan tampilan perpustakaan yang tidak memerlukan dependensi npm seperti Sutil atau Elmish.Snabbdom (atau bahkan React jika Anda menggunakannya dari CDN) mungkin akan membantu terutama bagi pendatang baru jika Fable dapat melakukan (atau setidaknya memanggil) operasi dasar untuk tulis frontend aplikasi web: bundling dan server dev. Untuk itu kami akan menyertakan argumen CLI baru seperti --serve dan/atau --bundle .

Menulis bundler kami sendiri tidak bisa dilakukan. Pada awalnya saya pikir kita dapat menyematkan bundler dalam paket Fable, tetapi mungkin lebih mudah untuk membuat dir .fable-tools yang tersembunyi, menginstal di sana alat yang diperlukan dengan npm dan memanggilnya seperlunya. Yang ideal adalah mengandalkan bundler dengan default yang baik tetapi itu dapat disesuaikan jika perlu. Pertanyaannya, bundler apa yang digunakan?

  • Webpack: opsi yang paling diperluas dan mungkin lebih disukai saat pengguna perlu menyesuaikan. Default mungkin tidak akan cukup tetapi kami dapat membuat webpack.config otomatis dan jika perlu biarkan pengguna menyesuaikannya. Jika saya tidak salah begitulah cara kerja create-react-app.
  • Parcel: ini akan menjadi kandidat yang sangat baik, karena memiliki banyak default yang bagus, tetapi mereka tampaknya terjebak dalam peningkatan v2 selamanya.
  • Rollup: kami kadang-kadang menggunakannya di Fable karena kemudahan penggunaannya, tetapi baru-baru ini saya merasa kurang dan sulit untuk menyesuaikannya, terutama server dev.
  • Lainnya? Saya kehilangan jejak bundler baru seperti Snowpack atau apa pun namanya sekarang

Ada pendapat? Ingat ini hanya opsional dan pengguna masih dapat memilih bundler lain seperti sekarang.

discussion

Komentar yang paling membantu

Kamu benar. Ini mungkin salah satu hal yang membuat saya bersemangat dan menyesal setelahnya Ok, mari kita tutup ini. Sekarang semuanya menjadi lebih stabil, cara untuk membuat segalanya lebih sederhana bagi pendatang baru adalah dengan meningkatkan templat :+1:

Semua 3 komentar

Saya tidak berpikir ini adalah ide yang baik. Ini akan membuat batas antara F# dan dunia JavaScript menjadi kabur lagi. Mirip dengan bagaimana di Fable 2 di mana orang mengalami kesulitan memahami apa yang bertanggung jawab atas apa.

Fable 3 luar biasa karena begitu Anda memanggil Fable untuk menghasilkan file JavaScript maka Anda langsung berada di dunia JavaScript. Jadi Anda dapat menemukan semua dokumentasi yang Anda inginkan tentang subjek yang dibuat oleh komunitas JavaScript.

Saya lebih suka dokumentasi yang dibuat dengan baik yang menjelaskan bagaimana Fable 3 bekerja mulai dan berhenti (mengkompilasi F# ke JS) dan kemudian menjelaskan kepada orang-orang dari sini Anda dapat menggunakan alat yang Anda inginkan. Dan memiliki dokumentasi dokumentasi sederhana yang menjelaskan bagaimana melakukannya dan kemudian mendelegasikan penjelasan tersebut ke dokumentasi alat yang dipilih.

IHMO, orang perlu memahami ekosistem tempat mereka bekerja/bersama. Ya, untuk etalase yang sangat sederhana, Anda dapat mengabaikan cara kerja JavaScript dan sebagainya. Tapi, segera Anda perlu memahami gambaran besarnya agar dapat menulis aplikasi Anda.

Jika kita berada di posisi yang sama dengan bahasa yang mengontrol 100% saluran dan ekosistem mereka seperti Elm, saya akan berpikir berbeda.


Untuk alasan yang sama, saya lebih suka menggunakan concurrently untuk memanggil Fable dan bundler JavaScript secara berdampingan. Alih-alih membuat Fable, aktifkan bundler JavaScript.

Tidak banyak, tetapi "menunjukkan" bahwa mereka bekerja berdampingan tanpa sihir. Ketika kita menjalankan dotnet fable --run XXX tidak jelas bahwa perintah tersebut hanya akan dijalankan sekali bahkan jika Anda berada dalam mode menonton.

IHMO, dalam semua detail kecil inilah kita dapat memperoleh kejelasan/transparansi tentang cara kerja/operasinya.

Pendapat pribadi saya, seperti yang diungkapkan dalam diskusi sebelumnya tentang topik tersebut, adalah masuk akal untuk mengadopsi dan tetap berada dalam tujuan desain yang juga dimiliki oleh transpiler lain seperti TypeScript, terutama bagian "non-tujuan" (yaitu "kami tidak ingin melakukan itu"), dan pada topik khusus ini, "non-tujuan" terdekat adalah nomor 4.

Kamu benar. Ini mungkin salah satu hal yang membuat saya bersemangat dan menyesal setelahnya Ok, mari kita tutup ini. Sekarang semuanya menjadi lebih stabil, cara untuk membuat segalanya lebih sederhana bagi pendatang baru adalah dengan meningkatkan templat :+1:

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

MangelMaxime picture MangelMaxime  ·  3Komentar

AngelMunoz picture AngelMunoz  ·  4Komentar

krauthaufen picture krauthaufen  ·  3Komentar

theprash picture theprash  ·  3Komentar

MangelMaxime picture MangelMaxime  ·  3Komentar