Sinon: Proposal: ekstrak xhr palsu dan server palsu ke modul terpisah

Ping: @cjohansen @fatso83 @fearphage @jonnyreeves @mantoni @lucasfcosta

Benar-benar mendukung mengekstraksi mereka. Rencana Anda untuk tidak digunakan lagi dan kemudian dihapus masuk akal. Saya bertanya-tanya apakah kita harus menghentikan jurusan dan menghapus jurusan berikut, karena kebanyakan orang akan menerima peningkatan implisit dalam build mereka melalui ^ dependensi.

Kami membicarakan ini sebelumnya, dan semua setuju saat itu, jadi ya: masih mendukung.

@mantoni Tanda sisipan tidak akan memutakhirkan versi utama, bukan? Pikir itu akan melakukan patch dan versi minor, tetapi tidak mayor. Itu akan sangat tidak masuk akal.

Tidak melihat titik besar dalam mencela sekarang karena kami menghilangkan sebagian besar rintangan untuk melakukan rilis besar lebih sering, tetapi jika itu membantu dengan cara apa pun: tentu saja, mengapa tidak.

@fatso83 Ya, ^ hanya update minor dan patch. Pertanyaan saya adalah: Apakah kami menambahkan peringatan penghentian dalam rilis kecil, atau besar? Jelas, kami akan menghapus API di jurusan (lain).

Seperti konsepnya. Bukan penggemar tes dan sumber yang tinggal bersebelahan ( histeria massal ), tapi itu sesuatu yang bisa kita kerjakan nanti.

hapus fake-xhr-and-server dari sinon

Bisakah kita bekerja dengan nama yang lebih baik? sinon-networking ? sinon-net ? Hanya membuang barang di luar sana.

kita harus mencela di jurusan dan menghapus jurusan berikut

Sepakat.

Pertanyaan: Jika kita terus mengeluarkan sesuatu (seperti sinon-test dan sekarang ini), apakah tujuan sinon (repo ini) hanya menjadi paket meta yang hanya merupakan kumpulan paket lain?

Bisakah kita bekerja dengan nama yang lebih baik? sinon-networking ? sinon-net ?

Semua saran diterima

Saya tidak menentang menemukan nama yang lebih baik, tetapi mungkin sinon-networking akan menyiratkan cakupan yang lebih luas daripada yang dimiliki kode saat ini? Tidaklah pantas bagi seseorang untuk mengharapkan sinon-networking juga mendukung permintaan http node yang mengejek. Mungkin tidak masalah, hanya membuangnya di sana.

Jika kita terus mengeluarkan sesuatu (seperti sinon-test dan sekarang ini), apakah tujuan sinon (repo ini) hanya menjadi paket meta yang hanyalah kumpulan paket lain?

Tujuan saya dengan upaya ini adalah untuk menghapus XHR Palsu dan Server Palsu dari penawaran inti sinon, dan menerbitkannya sepenuhnya secara terpisah.

Saya tidak berpikir mereka diperlukan untuk sebagian besar pengguna / proyek. XHR palsu memiliki cakupan spesifikasi yang tidak lengkap, sangat rumit dan menarik laporan bug dalam jumlah yang tidak sedikit tetapi tidak terlalu banyak permintaan tarik.

Sebagai paket mandiri, kita akan mendapatkan gambaran yang lebih jelas tentang berapa banyak yang digunakan.

Pada akhirnya, saya pikir persembahan inti sinon harus terdiri dari

• Mengintai
• rintisan
• Mengejek
• Bak pasir
• Pernyataan
• Matcher

Saya sangat setuju dengan apa yang baru saja dikatakan @mroderick .

Mungkin kita bisa menyebutnya sinon-xhr , btw.

Namun, saya pikir semakin cepat kami menghapusnya, semakin baik. Baru-baru ini saya telah membaca banyak tentang bagaimana Go dirancang dan saya semakin tertarik untuk memberikan pengguna minimal untuk membangun di atas fitur yang kami sediakan dengan cara yang elegan dan ringkas. IMO memiliki Fake XHR dan Fake Server bertentangan dengan prinsip ini karena fakta bahwa mereka lebih kompleks untuk digunakan daripada hanya stubs yang memungkinkan kami memalsukan jawaban atas permintaan itu sendiri. mengejek utilitas global seperti XMLHttpRequests atau memberikan " Fake Server " yang akhirnya sama dengan rintisan.

Saya pikir menambahkan peringatan penghentian pada minor/tambalan akan baik sehingga orang dapat menyiapkan kode mereka dan mengadopsi mayor ASAP berikutnya. Kami bahkan dapat menambahkan peringatan tersebut sebelum melakukan tindakan apa pun terkait pemisahan repositori / paket karena ini sudah menunjukkan niat kami untuk menghentikannya sebelumnya.

Lagi pula, saya pikir saya sudah diperpanjang terlalu banyak.

TL;DR saya setuju

Saya telah memperbarui deskripsi di atas agar lebih sesuai dengan pendapat yang diajukan.

Hal-hal hebat, Morgan, tapi saya tidak yakin saya cukup memahami poin-poin ini dalam deskripsi baru:

• Impor nise kembali ke sinon, pertahankan api yang sama persis, tambahkan peringatan penghentian
• Publikasikan versi UTAMA baru, yang menghapus penghentian lama, dan menggunakan nise untuk xhr dan server palsu
• Beberapa waktu di masa depan, hapus nise dari sinon di versi mayor baru

Saya mengerti bahwa masuk akal untuk mulai menambahkan peringatan penghentian (yang saya asumsikan mengatakan "berhenti menggunakan API ini - mulai gunakan lib terpisah nise dan fake-fetch sebagai gantinya") sekarang kami berencana untuk menghapus API jaringan dari inti. Tapi saya tidak mengerti langkah di mana kami menghapus penghentian? Dan dikatakan "... menggunakan nise untuk xhr dan server palsu" - yang sudah terlihat dari langkah sebelumnya. Saya akan menganggap langkah-langkahnya adalah:

1. ganti modul saat ini dengan nise secara internal sambil tetap mempertahankan api yang sama dan menambahkan peringatan deprecation
2. rilis versi utama
3. rilis versi utama baru di mana kami menjatuhkan metode api terkait penghentian jaringan

Tolong jelaskan, karena saya pikir saya mungkin gagal memahami maksud Anda: smile_cat:

Tapi saya tidak mengerti langkah di mana kami menghapus penghentian?

Mungkin saya tidak jelas;

Ketika saya menulis

menghapus penghentian lama

Saya bermaksud mengatakan bahwa karena kami merilis versi MAJOR baru, maka sebaiknya kami mengambil kesempatan untuk menghapus semua hal yang tidak digunakan lagi di 2.x . Seperti ProgressEvent dan hal-hal lain yang harus tetap pribadi.

Apakah server Sinon akan menjadi paket independen? Apakah akan terus dipertahankan?

Ini cukup berguna, setidaknya untuk aplikasi khusus di mana kita perlu menjalankan tes integrasi melalui kerangka kerja eksternal (misalnya Busur Derajat/Webdriver) _tanpa_ Sinon itu sendiri, tetapi mencegat dan mematikan _real_ permintaan XHR di browser melalui server Sinon yang disuntikkan ke dalam browser dengan kerangka kerja ini (jadi pengujian itu sendiri masih dijalankan di luar browser).

Yaitu aplikasi kita hanya membutuhkan (pada kenyataannya, bergantung pada) fungsionalitas server Sinon. Menyediakannya sebagai paket yang berdiri sendiri (jauh lebih kecil) (seperti yang dilakukan di 1.x!) sebenarnya akan cukup bagus. Tanpa itu, kita harus menjalankan server "eksternal" yang akan meningkatkan kerumitan pengaturan pengujian.

@dinvlad Jika Anda membaca deskripsi masalah di atas, Anda akan melihat bahwa paket yang diekstrak (dengan nama yang diusulkan nise ) menggambarkan dirinya sebagai mandiri. Apakah akan terus dipertahankan tergantung masyarakat. Kami ingin fokus pada pemeliharaan inti, karena proyek sampingan seperti lolex , sinon-test dan nise mengurangi jam yang tersedia dari paket utama Sinon.

Kedengarannya masuk akal. @mroderick , terima kasih telah mengerjakannya!

Mengapa nise ? Aku merindukan bagian itu.

Mengapa nise ? Aku merindukan bagian itu.

Ini adalah kata sifat dalam bahasa Jepang, yang berarti "palsu" ... yaitu xhr palsu, server palsu, berita palsu, dll.

Saya telah membuat repositori sinonjs/nise , dan telah membuat PR pertama untuk mengimpor xhr palsu dan server palsu dari repositori ini: https://github.com/sinonjs/nise/pull/1

Melihat ini telah digabungkan ke dalam inti, saya menutupnya.