Definitelytyped: Kenapa monorepo?

1. Anda dapat menavigasi langsung ke folder di bawah types . Misalnya, untuk melihat jenis jquery , navigasikan ke https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery .
2. Anda dapat mencari nama perpustakaan. Misalnya, jika Anda ingin mencari masalah terbuka yang berkaitan dengan lodash , maka Anda dapat membuka https://github.com/DefinitelyTyped/DefinitelyTyped/issues?utf8=%E2%9C%93&q=is% 3Amasalah+adalah%3Aterbuka+lodash ; atau Anda dapat menggunakan bilah pencarian, yang akan mengarahkan Anda ke string kueri yang sesuai.

Bukankah monorepo ini benar-benar berantakan?

Cara termudah untuk melakukannya adalah dengan menggunakan TypeSearch . Anda akan mengetahui apakah jenisnya ada di registri, dan jika ya, tautan dalam deskripsi npm akan menunjuk persis ke subfoldernya.

Non-monorepo adalah nonstarter. Seringkali, kontributor yang memodifikasi sesuatu dalam satu paket @types perlu memodifikasi beberapa paket hilir untuk memperbaiki jeda atau mengaktifkan fungsionalitas baru; ini adalah kebakaran tempat sampah mutlak dengan alur kerja GitHub karena tidak ada cara terintegrasi untuk menggabungkan PR tersebut secara atom sambil tetap menjalankan CI yang masuk akal yang dibangun di atas semuanya. Jika Anda pikir Anda melihat 4.000 folder adalah masalah, bayangkan kita berusaha untuk menjaga pengaturan GitHub disinkronisasi di 4.000 repo.

Seringkali, kontributor yang memodifikasi sesuatu dalam satu paket @types perlu memodifikasi beberapa paket hilir untuk memperbaiki jeda atau mengaktifkan fungsionalitas baru

Saya tidak terbiasa menulis paket @types/ , jadi mungkin saya melewatkan sesuatu...

Tapi bukankah itu gunanya semver ?
Apa yang istimewa dari penerapan paket @types/ , terhadap paket lain di npm?

Saya berharap ini berfungsi sama: grafik ketergantungan di mana Anda memiliki mis. paket @types/X dan paket hilir @types/Y yang menggunakan @types/X . Keduanya dipelihara oleh orang yang berbeda. Ketika @types/X diubah, itu diterbitkan dengan versi yang berbeda, sehingga tidak akan langsung mempengaruhi @types/Y . Kontributor @types/Y kemudian memutuskan untuk memperbarui ke versi @types/X dan memperbaiki masalah karena semua perubahan yang melanggar.

Mungkin di atas itu Anda memiliki DefinitelyTyped meta-repository, yang hanya menyimpan daftar tautan ke type-repos. Dan kemudian beberapa skrip publisher yang berjalan melalui daftar itu dan menerbitkan semua paket di bawah @types/ npm-namespace.

Atau jika memungkinkan, izinkan pelaksana untuk memublikasikan langsung di bawah @types namespace. Jadi kita tidak membutuhkan meta-repo DefinitelyTyped sama sekali.

https://github.com/npm/npm juga 2k masalah.
https://github.com/moby/moby bahkan lebih.

Solusi terbaik adalah penulis mempertahankan definisi, yang selalu didorong.

@franklinyu Jumlah masalah bukanlah yang dipertanyakan. Mempertimbangkan repo ini mengumpulkan> 4k pengetikan, sejumlah besar masalah itu tidak masalah.

Pertanyaan sebenarnya adalah: masalah apa yang coba dipecahkan oleh DefinitelyTyped dengan menggabungkan semua pengetikan dalam satu repo?

Sayangnya, semver tidak berfungsi dengan baik untuk paket pengetikan. Versi major.minor dari paket types harus cocok dengan major.minor dari paket javascript, jika tidak, orang tidak akan tahu versi @types akan digunakan untuk versi paket javascript yang diberikan.

Misalnya, sekarang jika Anda menginstal [email protected] , maka Anda juga akan menginstal @types/[email protected] (sekarang di 4.14.109 ). Namun, bayangkan ada bug dalam tipe lodash (dan percayalah ini sering terjadi), dan seseorang memperbaikinya. Sekarang untuk apa kita menabrak nomor versi? Menurut definisi, setiap perubahan pada definisi tipe adalah perubahan antarmuka yang melanggar (atau setidaknya penambahan antarmuka). Tetapi kami tidak dapat menambahkan versi ke 4.15.0 karena tipe ini untuk 4.14 , bukan 4.15 . Dan kami tentu tidak ingin menaikkan nomor versi menjadi 5.0.0 . Jadi kita ganti nomor versinya menjadi 4.14.110 , meskipun ada perubahan antarmuka, karena sebenarnya antarmuka yang lama tidak akurat.

@aj-r Ok, major.minor versi @type/X harus sama dengan major.minor versi X , dan jika ada bug di @type/X Anda menggunakan versi patch untuk memperbaikinya. Kedengarannya benar.

Apa hubungannya dengan pertanyaan awal: monorepo vs repo terpisah?

Maaf, saya seharusnya sudah jelas - saya membahas salah satu komentar Anda sebelumnya:

Tapi bukankah itu gunanya _semver_?

masalah apa yang coba diselesaikan oleh PastiTyped dengan menggabungkan semua pengetikan dalam satu repo?

Apa masalah adalah berpisah DT menjadi 4.000 repo GitHub terpisah akan memecahkan?

Setiap hari anggota tim TypeScript mengelola backlog PR, menggabungkan atau meninjau beberapa lusin PR. Bot mengawasi volume besar PR yang kami dapatkan. Kami menjalankan aturan lint di seluruh repo yang menangkap kesalahan umum, dan kami mengaktifkan aturan lint baru secara teratur saat kami memikirkan aturan yang akan membantu. Kami menemukan dan memperbaiki definisi dengan hal-hal yang rusak oleh versi kompiler mendatang.

Membagi ini menjadi ribuan subrepo membuat semua itu lebih sulit, dan tidak membuat yang lain lebih mudah. Jadi mengapa kita melakukannya?

Masalah apa yang akan dipecahkan oleh DT menjadi 4.000 repo GitHub terpisah?

1. Sebagai pengguna, Anda mencapai sumber lebih cepat. Anda tidak perlu menggunakan beberapa aplikasi tambahan seperti TypeSearch untuk menjangkau sumber. Di npm Anda memiliki tautan langsung ke repo pengetikan yang diperlukan.

2. Sebagai pengguna, lebih mudah untuk melihat masalah saat ini dan mengajukan yang baru.

   • Anda tidak perlu mencari dan memfilter pada satu repo besar dengan >2k masalah. Bagaimana jika pelapor lupa untuk mengikuti aturan penamaan masalah (mis. [@types/name-of-package] Issue description )? Anda tidak pernah menemukan masalah yang dibutuhkan.
   • Karena itu, file duplikat menjadi lebih kecil kemungkinannya.

3. Sebagai kontributor, Anda dapat dengan jelas memantau berapa banyak masalah yang Anda miliki di repositori Anda.

   • Anda tidak perlu (lagi) memfilter apa pun untuk mendapatkan masalah untuk pengetikan konkret Anda. Kurang mungkin untuk melewatkan masalah yang dibutuhkan.
   • Anda memiliki motivasi yang jelas untuk menjaga agar masalah tetap rendah. Masalah nomor bukan tanggung jawab bersama lagi.
   • Karena itu, kecil kemungkinannya untuk melupakan masalah yang menggantung di sana selama bertahun-tahun .
     Misalnya. ada 1 halaman terbitan tahun 2013, 5 halaman terbitan tahun 2014, dan seterusnya.

4. Sebagai anggota tim TypeScript, Anda menghabiskan lebih banyak waktu untuk meningkatkan TypeScript itu sendiri (mis. Dukungan jsdoc), daripada memelihara/menggabungkan/meninjau ribuan pengetikan untuk banyak paket npm di luar sana.
   Dalam ekosistem yang matang, itulah yang harus dilakukan komunitas.

   • Kami menjalankan aturan lint di seluruh repo yang menangkap kesalahan umum

     Lepaskan lint preset dengan semua aturan yang disarankan, dan sarankan semua kontributor untuk menggunakan versi terbaru dari preset itu.

   • Kami menemukan dan memperbaiki definisi dengan hal-hal yang rusak oleh versi kompiler mendatang.

     Itulah yang harus dilakukan oleh kontributor komunitas. Versi ts-compiler yang diharapkan harus dinyatakan dengan jelas di bagian peerDependency dari package.json dari paket-pengetikan, jadi ini memperingatkan Anda ketika Anda menggunakannya di lingkungan yang salah.

Anda mendekati ini dari pola pikir bahwa mengetik sebenarnya dimiliki oleh siapa saja. Kenyataannya adalah bahwa sebagian besar file dalam repo ini ditulis sekali oleh seseorang yang menjalankan dts-gen dan memeriksanya dengan beberapa perbaikan, kemudian disentuh setahun sekali oleh tiga orang lainnya. Tidak ada model kepemilikan yang kuat di sini, juga tidak perlu ada.

Apa yang terjadi ketika "pemilik" ad-hoc yang mendeklarasikan diri dari salah satu repo ini memutuskan untuk berhenti memeliharanya? Ini terjadi sepanjang waktu . Bagaimana kami melacak repo mana yang "terbaik" saat ini? Apa yang terjadi jika mereka mulai menggabungkan perubahan yang menghasilkan hal-hal yang tidak dapat kami publikasikan di NPM?

Ini juga hanya membuat hidup lebih buruk bagi orang-orang yang ingin mengirimkan perbaikan. Tahun lalu kami menambahkan parameter tipe ke file definisi React yang memerlukan perubahan hilir dalam beberapa ratus file. Adakah yang ingin mengkloning beberapa ratus repo (oh, dan repo mana ?) untuk membuat perubahan yang luas, lalu mengelola beberapa ratus permintaan tarik bersamaan? Bahkan tidak ada alat untuk ini di mana pun.

Sebagai anggota tim TypeScript, Anda menghabiskan lebih banyak waktu untuk meningkatkan TypeScript itu sendiri (mis. Dukungan jsdoc), daripada memelihara/menggabungkan/meninjau ribuan pengetikan untuk banyak paket npm di luar sana. Dalam ekosistem yang matang, itulah yang harus dilakukan komunitas.

Kami benar-benar mencoba ini dan itu tidak berhasil. DT semata-mata didorong oleh komunitas dan menghasilkan backlog permintaan tarik hingga ratusan. Sejak itu waktu rata-rata untuk menggabungkan PR telah turun dari 2 minggu menjadi 4 hari (yang merupakan minimum yang disengaja sehingga orang memiliki waktu untuk mempertimbangkan perubahan), meskipun volume PR telah meningkat dari ~200/bulan menjadi ~1.000/bulan .

Oke, saya rasa saya punya jawaban atas pertanyaan awal saya "Mengapa monorepo?":
Karena lebih mudah bagi tim TypeScript untuk mempertahankan definisi tipe (mempertimbangkan dependensi tipe, pembaruan atom untuk paket hilir, CI, linting, dll.)

Saya masih berpikir bahwa model di mana tim TypeScript mengambil peran utama dalam memelihara ribuan paket sebagian besar dengan sendirinya agak aneh. Terutama di dunia npm modular yang digerakkan oleh komunitas.

Tetapi jika model ini cocok untuk Anda. Lalu oke :smiley:

@art-in Saya tidak percaya tujuannya adalah untuk mengelola semua jenis dari repo yang satu ini, ini untuk mengelola jenis yang tidak disediakan oleh paket itu sendiri. Jika sebuah paket ingin memublikasikan tipe untuk paketnya, paket tersebut dapat melakukannya langsung di dalam paket. PastiTyped hanyalah tempat di mana tipe dapat diagregasi tanpa memerlukan persetujuan dari pengelola paket asli.