GitHub `pushed_at` Menyesatkan pada 14 dari 35 Repositori Scraping; Bot Terbukti pada Tiga

Halaman repositori GitHub menampilkan pushed_at, yaitu cap waktu yang bisa berubah setiap kali ada push ke branch mana pun. Akibatnya, nilainya bisa beda dari commit terbaru di default branch. Tanggal di default branch adalah sinyal perawatan repositori; itu belum tentu kode yang dipasang oleh package manager.

Package manager biasanya mengambil artefak registry atau versi modul. Karena itu, audit ini memeriksa aktivitas repositori dan artefak yang dipublikasikan secara terpisah: salah satunya bisa saja masih baru sementara yang lain sudah usang.

Jadi, saya mengambil 35 repo yang masih muncul dalam rekomendasi, lalu membaca angka yang tidak ditampilkan GitHub di header: tanggal commit terbaru di default branch.

Perbedaannya jelas: dari 35 repo, ada 14 yang pushed_at-nya lebih dari 180 hari lebih baru daripada commit default branch terakhir, dengan selisih tertinggi mencapai 1.802 hari. Bot terkonfirmasi pada tiga dari 14 kasus tersebut; setelah difilter dari repo arsip dan aktivitas manusia, tersisa dua kasus bot terkonfirmasi dari sembilan kandidat. Temuan yang lebih penting: kebaruan repositori dan kebaruan artefak yang dipublikasikan bisa berjalan sendiri-sendiri.

Apa yang diukur, dan berdasarkan apa

Referensi resmi: GitHub repository API.

Seluruh angka di sini dibaca dari respons API langsung antara 15:44 hingga 15:53 UTC pada 2026-07-27 dan disimpan dalam cache. Dataset 35 baris, daftar repositori, baris yang dibangun, serta skrip fetch/build di artifacts/ menyimpan input audit dan kode transformasinya.

Empat kategori data dikumpulkan; permintaan registry dan activity dilakukan secara kondisional, bukan empat panggilan seragam yang dipukul rata:

• GET /repos/{owner}/{repo} — stars, archived, pushed_at, license, default_branch.
• GET /repos/{o}/{r}/commits?sha={default_branch}&per_page=1 — commit terbaru di default branch, dipakai sebagai sinyal perawatan repositori.
• GET /repos/{o}/{r}/activity?per_page=30 — untuk setiap repo yang dua angka tadi tidak cocok, apa yang sebenarnya menggerakkan pushed_at.
• GET /repos/{o}/{r}/releases plus registry PyPI dan npm — kapan artefak terakhir dirilis, yang ternyata lebih penting daripada keduanya.

staleness_days adalah selang waktu dari commit default branch ke momen acuan. Selisih antara pushed_at dan commit tersebut adalah ilusi, diukur dalam hari. Apa pun di atas 180 hari diberi penanda.

Ada dua disiplin yang perlu disebutkan karena keduanya mengubah hasil.

Atribusi package selalu diverifikasi, tidak pernah diasumsikan. Package yang README-nya menyebut sebuah repo belum tentu package dari repo itu. Setiap pemetaan harus dikonfirmasi lewat field terstruktur — entri repository/project_urls milik registry, atau manifest yang memang ada di dalam repo. Enam pemetaan yang kelihatannya meyakinkan gagal lolos aturan ini, dan jumlah download-nya sengaja tidak diatribusikan.

Salah satu penolakan itu layak dijadikan contoh. curl-cffi menarik 35.763.529 download per bulan dan, dari jauh, tampak seperti binding Python untuk lwthiker/curl-impersonate — sebuah repo yang sudah dingin selama 875 hari. Kalau diatribusikan, angkanya akan menjadi 44 kali lebih besar daripada newspaper3k, dan itu salah: metadata PyPI milik curl-cffi justru mengarah ke lexiforest/curl_cffi, proyek terpisah yang masih aktif dan terakhir dirilis pada 2026-04-03. Angka paling mencolok di sini justru yang keliru.

Kasus ketujuh lebih aneh lagi: steel-dev/steel-mcp-server menyatakan @steel-dev/mcp-server di package.json-nya sendiri, tetapi npm mengembalikan 404. Paket itu tidak pernah dipublikasikan, jadi klaim “masih diinstal” sama sekali tidak bisa benar.

Kalau angkanya tidak bisa diperoleh, itu dinyatakan apa adanya. Tool Go, JVM, .NET, dan PHP tidak punya keberadaan di PyPI atau npm, jadi mereka diberi label N/A (no PyPI/npm package) — bukan nol. Tujuh belas dari 35 repo tidak mempublikasikan GitHub Releases sama sekali; itu dicatat sebagai none, bukan data hilang.

Field-field ini sengaja tidak digabung menjadi satu “skor kesehatan.” Default branch yang usang, side branch yang baru, GitHub Release yang tidak ada, dan artefak registry yang lama menjawab pertanyaan yang berbeda. Bukti per baris tersedia di dataset 35 baris, bersama input repositori dan rekaman yang dibangun. Bacalah itu sebagai sinyal triase untuk menentukan pemeriksaan berikutnya, bukan sebagai empat suara yang memutuskan apakah sebuah proyek masih hidup.

Catatan tentang sampel, sejak awal

Ini adalah daftar buatan tangan dari tool yang saya curigai hanya bertahan karena reputasinya. Ini bukan sampel acak dari ekosistem scraping, dan “31 dari 35 sudah usang” bukan angka tingkat ekosistem — itu lebih dekat ke ukuran seberapa baik saya memilih sampelnya. Hasil yang menarik bukan jumlah yang usang. Yang menarik adalah bahwa bahkan pada sampel yang dipilih untuk fenomena ini, mekanisme spesifik yang saya uji hanya menjelaskan sebagian kecil kasus, dan bisa dikonfirmasi secara positif pada lebih sedikit lagi.

Ilusinya nyata, dan ini kasus terburuknya

sjdirect/abot, crawler .NET dengan 2.308 stars. GitHub menampilkan push pada 2026-07-17, sepuluh hari sebelum tanggal acuan. Padahal default branch terakhir disentuh pada 2021-08-09.

Itu selisih 1.802 hari. Lima tahun. Header bilang baru pekan lalu.

Ada 14 dari 35 repo yang selisihnya lebih dari 180 hari:

Empat belas dari tiga puluh lima. Nyata, penting untuk diketahui, dan tetap hanya sebagian kecil dari sampel yang memang dipilih agar memuatnya.

Bot terkonfirmasi pada tiga repo yang ditandai — dan dua tetap tersisa setelah difilter

Versi umum dari cerita ini selalu menyebut dependabot. Saya cek dengan mengambil activity feed untuk setiap repo yang ditandai dan mengklasifikasikan semua ref yang di-push setelah commit default branch terakhir. Kata “setelah” itu penting: event yang terjadi sebelum commit terakhir tidak menjelaskan apa yang membesarkan selisih, dan menghitung seluruh feed diam-diam mengubah pertanyaannya.

Terkonfirmasi digerakkan bot, dengan metode pasca-commit: tiga. scrapinghub/splash (4 dari 4 event pasca-commit pada dependabot/pip/*), geziyor/geziyor (5 dari 5 pada dependabot/go_modules/*), apache/any23 (16 dari 16 pada dependabot/maven/*). Salah satu dari tiga itu, any23, secara resmi diarsipkan, jadi tidak pernah masuk ke set yang difilter — menyisakan dua kasus terkonfirmasi yang juga memenuhi semua kondisi lain.

Salah total: dua, dan keduanya lebih menarik daripada cerita bot-nya.

Selisih 1.520 hari pada dragnet-org/dragnet berasal dari manusia yang mendorong branch bernama mp/py3.10 — port Python 3.10 yang belum digabung. Seseorang mencoba membawa proyek itu maju lalu berhenti. Itu bukan noise otomatis yang menggembungkan cap waktu; itu catatan nyata bertanggal tentang upaya penyelamatan yang gagal. Bisa dibilang ini justru sinyal paling berguna di seluruh dataset, dan framing “dependabot yang melakukannya” akan menghapusnya.

Campuran, dan lebih besar dari keduanya: dua. crawlab-team/crawlab punya 12.250 stars — repo dengan stars terbanyak kedua dalam sampel — dan selisih 488 hari pada main. Feed-nya memuat branch dependabot dan 24 push pasca-commit dari manusia, semuanya ke develop dan test. Orang yang hanya melihat header akan melihat Februari 2026 dan mengira proyek sehat; orang yang membaca main akan melihat Oktober 2024 dan mengira proyek mati. Keduanya salah. Pengembangan berpindah dari default branch, sesuatu yang memang sering terjadi pada proyek, tetapi ringkasan GitHub tidak punya cara untuk mengatakannya. sjdirect/abot adalah kasus campuran lainnya: push yang menaikkan pushed_at-nya memang dari dependabot, tetapi manusia mendorong upgrade1 pada 2024, itulah sebabnya ia nantinya keluar dari set yang difilter.

Rhizome-Conifer/conifer adalah kasus yang ambigu, dan awalnya saya membacanya keliru. Default branch-nya adalah main, bukan master, dan main sudah diam sejak 2023-10-12 — satu-satunya event main di feed adalah pembuatan branch pada Januari 2025, konsisten dengan proses rename. Sementara itu, satu akun mendorong conifer-twilight dan twilight/read-only pada 2026-07-22, lima hari sebelum tanggal acuan. Itu aktivitas manusia yang nyata, tetapi “masih aktif dikembangkan” lebih dari yang bisa dibuktikan refs-nya: satu kontributor, pada branch bernama read-only, sama masuk akalnya dengan proyek yang sengaja ditutup pelan-pelan seperti dengan pengembangan berkelanjutan. Yang bisa dikatakan lebih sempit, namun tetap layak disebut, adalah: selisih 1.013 hari itu bukan noise bot, tetapi juga bukan bukti penelantaran.

Tidak diketahui: tujuh. php-html-parser, simhash-py, internetarchive/wayback, boilerpipe, waybackurls, wpull, dan crawler4j semuanya punya selisih yang terverifikasi, tetapi activity feed-nya kembali kosong.

Penjelasan yang menggoda adalah retensi — activity feed GitHub tidak mundur tanpa batas. Cache membantah itu untuk sebagian besar kasus. Event tertua di antara 123 respons ini adalah 2023-03-10, dan lima dari tujuh repo itu punya pushed_at yang masih berada nyaman dalam jendela itu: php-html-parser 2024-08-09, wpull 2024-04-29, waybackurls 2024-05-01, internetarchive/wayback 2024-03-01, simhash-py 2023-05-15. Apa pun yang menggerakkan cap waktu itu seharusnya terlihat di feed, tetapi tidak ada. Retensi hanya menjelaskan boilerpipe (2018) dan crawler4j (2021).

Jadi pernyataan jujurnya lebih sempit daripada penjelasan yang rapi: untuk tujuh repo, selisihnya adalah fakta terverifikasi dan penyebabnya belum ditetapkan — endpoint mengembalikan kosong, dan untuk lima di antaranya saya tidak bisa bilang kenapa. “Dependabot yang melakukannya” hanyalah asumsi untuk ketujuhnya.

Jika dijumlahkan, dari 14 repo yang ditandai:

Jumlah barisnya tepat 14. Mereka mengklasifikasikan apa yang menggerakkan pushed_at; mereka tidak membuktikan secara independen apakah sebuah proyek ditinggalkan.

Apa yang lolos filter penuh, dan apa arti “lolos”

Klaim awal membutuhkan empat hal sekaligus: usang lebih dari setahun, pushed_at membesar lebih dari 180 hari, tidak diarsipkan, dan tidak ada tanda bahwa pembengkakan itu berasal dari kerja manusia. Sembilan dari 35 kandidat lolos keempatnya, ditampilkan di sini bersama dua pengecualian yang paling penting:

Angka itu perlu satu kualifikasi yang tidak bisa dibawa filter. Hanya dua dari sembilan — splash dan geziyor — yang punya bukti positif bahwa botlah yang mendorong pembengkakan. Tujuh lainnya lolos syarat keempat karena tidak ada bukti ke arah mana pun. Mereka adalah kasus yang masih bertahan di bawah klaim, bukan kasus yang mengonfirmasinya. Dan konfirmasi terkuat di seluruh audit, any23 dengan 16 dari 16 event dependabot, justru dikeluarkan karena repo tersebut diarsipkan.

Perhatikan juga bahwa abot, kasus 1.802 hari, bukan salah satu dari sembilan. Rekamannya berisi push manusia, jadi ia gagal pada syarat keempat — ilusi paling dramatis dalam dataset ini bukan contoh bersih dari mekanisme yang diilustrasikannya.

Untuk 21 dari 35, GitHub menunjukkan keterlambatan itu secara gamblang

Inilah temuan yang paling merusak hipotesis saya. Empat belas repo memiliki selisih nol, dan tujuh lainnya berada di bawah 180 hari. Untuk 21 dari 35 kandidat, pushed_at memang sama dengan commit default branch terakhir. GitHub tidak menutupi apa pun.

Bahkan termasuk beberapa yang paling mati di sampel:

BuilderIO/gpt-crawler punya 22.374 stars dan header-nya mengatakan hal yang sama sejak 2025-07-07. Tidak ada yang disembunyikan, dan volume instalasi tetap berjalan.

Itu memaksa klaimnya turun menjadi lebih sempit: GitHub menyamarkan staleness hanya pada sebagian kecil kasus, dan pada mayoritas kasus ia menyatakannya dengan jelas sementara instalasi tetap berlanjut. Mengapa instalasi itu tetap berjalan berada di luar apa yang bisa dijawab data ini — angka di sini menghitung instalasi, bukan keputusan. Tetapi perubahan UI apa pun tidak menyelesaikan kelompok kedua, padahal kelompok itulah yang lebih besar.

Aktivitas repositori dan artefak yang dipublikasikan bisa berbeda arah

Baris paling mencolok di dataset ini mematahkan kerangka awal sepenuhnya.

codelucas/newspaper — 15.126 stars — masih aktif. Commit default branch terakhir bertanggal 2026-07-21, dengan tanggal acuan 2026-07-27, dan ditulis oleh maintainer. Semua pemeriksaan di level repo lolos.

Package yang dipasang semua orang adalah newspaper3k 0.2.8, dipublikasikan pada 2018-09-28. Umurnya 2.858 hari, dan masih menarik 813.513 download per bulan.

Default branch masih baru, sementara artefak PyPI belum dirilis sejak 2018. Ini membuktikan adanya jeda rilis, bukan alasan mengapa paket itu tidak dirilis atau apakah pipeline-nya rusak. Inilah risiko yang akan terlewat oleh pemeriksaan perawatan berbasis repositori saja, karena artefak registry-lah yang biasanya dijalankan setelah pip install newspaper3k.

Begitu Anda melihat package, bukan repo, polanya ada di mana-mana. Di antara 17 package yang atribusi repositorinya berhasil diverifikasi, 16 terakhir kali dirilis lebih dari setahun lalu, dan 16 itu menyumbang sekitar 2,28 juta instalasi per bulan dari total 2,30 juta:

tls-client layak disebut sendiri: 790.305 instalasi per bulan dari repo yang sudah dingin selama 905 hari, di kategori di mana tetap mutakhir adalah inti pekerjaannya. Perilaku TLS browser berubah; library yang berhenti mengikutinya sejak awal 2024 berjalan dengan asumsi awal 2024.

Ada dua catatan untuk tabel ini. Angka download registry mencakup proses CI dan mirror, serta tidak melakukan deduplikasi, jadi yang diukur adalah volume instalasi, bukan manusia. Dan jendela waktu rolling-nya tidak punya tanggal akhir yang sama — npm berakhir pada 2026-07-24, sedangkan pypistats relatif terhadap waktu pengambilan — jadi totalnya adalah penjumlahan bulan-bulan yang sedikit bergeser dan sebaiknya dibaca sebagai “sekitar 2,28 juta”, bukan angka presisi sampai digit terakhir.

Nama yang perlu diwaspadai karena sama

internetarchive/wayback adalah Java OpenWayback yang sudah mati, dingin selama 1.916 hari. wayback di PyPI adalah proyek yang sama sekali berbeda — edgi-govdata-archiving/wayback — dan kondisinya sehat, karena merilis 0.5.1 pada 2026-06-19, lima minggu sebelum tanggal acuan. Nama sama, kondisi berlawanan, tanpa hubungan. Ini salah satu dari enam atribusi yang ditolak, dan ini yang paling mungkin menjebak pengguna nyata: pencarian nama akan menampilkan keduanya, dan di salah satu halaman pun tidak ada penjelasan mana yang Anda temukan.

Diarsipkan, dinyatakan deprecated, dan tetap diinstal 127.232 kali per bulan

Enam repo dalam sampel berstatus archived: true, yang oleh GitHub dirender sebagai banner selebar penuh. Pembacaan awal saya adalah bahwa ini membuktikan orang mengabaikan peringatan keras. Cache menunjukkan ceritanya lebih buruk dari itu.

Referensi resmi: dokumen API hitungan unduhan npm.

Referensi resmi: dokumen deprecation npm.

@modelcontextprotocol/server-puppeteer menarik 127.232 instalasi per bulan dari modelcontextprotocol/servers-archived. Namun field npm repository-nya adalah null — tidak ada tautan dari halaman package kembali ke repo, jadi banner itu bukan sesuatu yang bisa dilewati oleh installer. Kebanyakan orang yang mengambil package ini bahkan tidak punya jalur menuju repositorinya.

Yang memang dipublikasikan npm adalah status deprecated-nya. Versi terbaru package ini membawa deprecated: "Package no longer supported. Contact Support at https://www.npmjs.com/support for more info." — yang dicetak npm ke terminal saat instalasi. Jadi peringatannya tersampaikan, di tempat pengguna benar-benar berada, dan 127.232 instalasi per bulan tetap berjalan. Itu temuan yang lebih kuat daripada sekadar banner, dan arahnya berbeda: sinyalnya bukan hilang, tetapi datang di tengah lautan output instalasi yang tidak memaksa siapa pun untuk membacanya.

browserbase/mcp-server-browserbase menunjukkan seperti apa penutupan yang rapi: commit default branch terakhirnya, pada 2026-07-20, secara literal berbunyi "Mark repository as archived and unmaintained (#198)". Para maintainer mengumumkannya, memberi tanggal, dan menandainya di API. Namun 20.389 instalasinya perlu dibaca hati-hati — jendela npm berjalan dari 2026-06-25 sampai 2026-07-24, jadi 26 dari 30 hari itu terjadi sebelum commit arsip. Angka itu terutama adalah permintaan sebelum pengumuman, bukan pembangkangan terhadapnya. Apa yang terjadi setelahnya benar-benar belum diketahui dari snapshot ini, dan saya ingin melihat ulang sebulan kemudian sebelum menyimpulkan apa pun.

57 stars, 204.025 instalasi per bulan

Janpot/microdata-node punya 57 stars dan menarik 204.025 download per bulan dari rilis bertanggal 2020-05-11.

Dengan 57 stars, microdata-node hampir tak terlihat di repositori dibandingkan volume di registry. Rasio instalasi terhadap star sebesar 3.579 banding 1 konsisten dengan penggunaan transitive, pengulangan di CI, mirror, atau konsumsi langsung oleh mesin. Audit ini tidak mengambil graph dependensi, jadi tidak bisa memilih di antara penjelasan-penjelasan tersebut.

Baris ini adalah pengingat untuk memeriksa eksposur tidak langsung, tetapi membuktikan penggunaan transitive memerlukan bukti reverse-dependency atau lockfile yang tidak dikumpulkan audit ini.

Usang bukan berarti rusak

Audit yang jujur harus mengatakan ini: tidak satu pun dari semua ini mengukur apakah sesuatu rusak. Yang diukur adalah apakah masih ada orang yang menjaga.

Sebagian di antaranya memang sudah selesai. SetSimilaritySearch mengimplementasikan algoritma kesamaan himpunan; algoritma seperti itu tidak “lapuk”. simhash adalah paper tahun 2007. Algoritma ekstraksi konten boilerpipe bekerja sama saja di 2026 seperti pada 2015 — terlepas dari akurasinya terhadap halaman modern, kodenya tidak bergeser di bawah kaki Anda.

Yang benar-benar lapuk adalah apa pun yang ujungnya berhadapan dengan target yang terus bergerak:

• Browser automation — setiap rilis Chrome bisa mematahkannya.
• Perilaku HTTP client yang meniru browser nyata — browser berubah, dan library yang beku berhenti cocok; tls-client ada di kategori ini.
• Parser khusus situs dan aturan ekstraksi per situs — setiap redesign situs adalah bug.
• Apa pun yang membungkus third-party API — vendor mengubah skema, dan Anda baru tahu di production.
• Apa pun yang membungkus LLM — deprecation model bergerak lebih cepat daripada semua ini.

Jadi, “stale 1.606 hari” adalah keadaan darurat untuk satu kategori, dan hampir tidak relevan untuk utilitas hashing. Tidak ada pengujian kerusakan di sini dan tidak ada klaim soal itu; mengelompokkan dependensi Anda sendiri berdasarkan kategori seperti ini tidak memerlukan biaya dan jauh lebih berguna daripada sekadar angka staleness.

Empat pemeriksaan yang benar-benar menjawab pertanyaan

Tidak satu pun dari ini adalah header repo.

Jalankan pemeriksaan 1, 2, dan 3 sebagai triase cepat. Lalu eskalasi ketika metadata repositori tidak ada, pemetaan package ambigu, aktivitas berpindah ke branch non-default, atau artefak registry berbeda arah dari repositori. Batas rate GitHub tanpa autentikasi dan latensi registry membuat janji satu detik tidak realistis.

Jika suatu pemeriksaan menemukan sesuatu yang dingin di kategori yang memang bergerak cepat, alternatif yang masih terawat di ruang ini sudah kami dokumentasikan dalam pengujian kami sendiri: Trafilatura untuk ekstraksi konten yang dulu dikerjakan dragnet dan boilerpipe, Scrapy atau Crawlee untuk framework crawling, Crawl4AI dan Firecrawl untuk ekstraksi berorientasi LLM, serta Scrapling ketika ketahanan lebih penting. Pilar open-source scraper kami melacak kumpulan yang lebih luas. Itu adalah ulasan pihak pertama; jalankan empat pemeriksaan ini sendiri sebelum mempercayai rekomendasi apa pun, termasuk dari kami.

Batasan data ini

• Pemilihan sampel. Dipilih manual karena dicurigai ditinggalkan. Tidak ada angka tingkat ekosistem yang bisa dibaca darinya.
• Tidak ada pengujian kerusakan. Tidak satu pun dari 35 tool ini dijalankan pada situs aktif. Staleness adalah sinyal perawatan, bukan vonis fungsional.
• Hitungan unduhan mencakup mesin. CI, mirror, tanpa deduplikasi, dan jendela waktu yang tidak punya tanggal akhir yang sama. Volume instalasi, bukan pengguna, dan bukan keputusan.
• Tujuh penyebab yang tidak diketahui tetap tidak diketahui. Activity feed tidak mengembalikan apa pun, dan untuk lima dari tujuh itu retensi tidak menjelaskannya. Membiarkan kolom kosong lebih baik daripada mengisinya dengan tebakan yang populer.
• staleness_days menggunakan tanggal committer. Riwayat yang ditulis ulang atau dimundurkan akan mendistorsinya. Tidak ada yang terdeteksi, dan itu tidak sama dengan tidak ada sama sekali.
• Satu tanggal acuan. 2026-07-27. Beberapa repo ini pasti sudah bergerak saat kamu membaca ini — newspaper khususnya melakukan commit secara rutin. Jalankan ulang empat pemeriksaan; jangan mengutip tanggal saya.

Saat layanan terkelola mengubah bentuk masalahnya

Setiap pemeriksaan di sini ada karena dengan library yang di-host sendiri, staleness adalah tanggung jawab Anda. Jika HTTP client yang beku berhenti berperilaku seperti browser terbaru, itu insiden Anda, kapan pun terjadinya.

Catatan penulis: Thunderbit adalah produk scraping terkelola kami. Layanan terkelola memindahkan sebagian tanggung jawab pemeliharaan ke vendor, tetapi cakupan, waktu respons, lock-in, dan kontinuitas vendor menjadi bagian dari model risiko. Thunderbit tidak dievaluasi dalam audit repositori ini.

Trade-off yang jujur: Anda kehilangan kemampuan membaca source, mengunci versi, dan memperbaikinya sendiri pada pukul 2 pagi. Bagi tim yang sudah memelihara scraper, jalur open-source sering kali tetap pilihan yang tepat — empat pemeriksaan inilah cara menjadikannya keputusan, bukan asumsi.

Coba Thunderbit untuk Ekstraksi Data Web

Ringkasan singkat

Saya membuat daftar ini untuk membuktikan bahwa GitHub menyembunyikan penelantaran. Ilusinya nyata pada 14 dari 35 repo dan paling mencolok pada satu kasus: sjdirect/abot menampilkan push pekan lalu padahal default branch-nya membeku sejak 2021, selisih 1.802 hari.

Namun mekanismenya lebih sempit daripada ceritanya. Sembilan repo lolos semua syarat yang dibutuhkan klaim itu, dan hanya dua dari sembilan itu — splash dan geziyor — yang punya bukti positif bahwa bot yang membuat angka itu membesar; sisanya lolos karena tidak ada bukti yang berlawanan. Dua repo yang ditandai ternyata adalah manusia yang mencoba, lalu gagal, menghidupkan proyek. Satu lagi, crawlab, punya 12.250 stars dan memang hanya memindahkan pengembangan ke develop. Untuk tujuh repo, activity feed kosong dan retensi tidak menjelaskan lima di antaranya, jadi penyebabnya belum ditetapkan, bukan diasumsikan. Dan untuk 21 dari 35 repo, GitHub melaporkan staleness secara akurat.

Kasus terburuk di dataset ini lolos semua pemeriksaan di level repo. codelucas/newspaper di-commit pada 2026-07-21; newspaper3k, yang terakhir dirilis pada 2018-09-28, masih terunduh 813.513 kali pada bulan itu. Di seluruh sampel, 16 package dengan rilis yang berumur lebih dari setahun menyumbang sekitar 2,28 juta instalasi per bulan.

Periksa commit default branch, tanggal rilis registry, flag archived, dan field deprecation npm sebagai triase awal. Selesaikan atribusi package-ke-repo dan pengembangan di branch non-default sebelum menarik kesimpulan.

Coba Thunderbit untuk Ekstraksi Data Web Get Started Free

FAQ

Apa itu pushed_at dan kenapa itu bukan berarti “last updated”? pushed_at adalah field GitHub API yang menjadi dasar cap waktu aktivitas di halaman repo, dan ia diperbarui ketika ada push ke branch mana pun. Commit terbaru di default branch adalah salah satu sinyal perawatan repositori, sedangkan package manager biasanya menginstal artefak registry atau versi modul yang sudah di-resolve. Dalam audit ini, 14 dari 35 repositori memperlihatkan dua tanggal GitHub yang berbeda lebih dari 180 hari.

Apakah selalu dependabot yang menggembungkan cap waktu itu? Tidak, dan itu justru bagian terlemah dari cerita populer tersebut. Jika hanya menghitung event yang terjadi setelah commit default branch terakhir, bot terkonfirmasi pada 3 dari 14 repo yang ditandai (splash 4 dari 4, geziyor 5 dari 5, any23 16 dari 16). Pada 2 kasus, klaim itu salah total: selisih dragnet berasal dari manusia yang mendorong port Python 3.10 yang belum digabung. Dua lainnya campuran, termasuk crawlab, di mana 24 push manusia masuk ke develop dan test sementara main tetap diam. Dan untuk 7 repo, activity feed sama sekali tidak mengembalikan apa pun, jadi penyebabnya belum ditetapkan — retensi hanya menjelaskan dua dari tujuh itu.

Apakah repo yang usang berarti tool-nya rusak? Berdasarkan data ini, belum tentu — tidak satu pun dari tool ini dijalankan pada situs aktif. Staleness penting sebanding dengan seberapa cepat targetnya berubah: browser automation, HTTP client yang meniru perilaku browser, parser khusus situs, dan wrapper API/LLM cepat kedaluwarsa, sedangkan library algoritmik seperti SetSimilaritySearch atau simhash bisa berumur bertahun-tahun dan tetap baik-baik saja. tls-client adalah kasus paling tajam dalam sampel, dengan 790.305 instalasi per bulan dari repo yang dingin selama 905 hari.

Bagaimana bisa repo aktif tetapi package-nya tetap mati? Itu codelucas/newspaper, dan itulah temuan paling penting dalam audit ini. Default branch-nya di-commit pada 2026-07-21, hanya beberapa hari sebelum tanggal acuan, tetapi newspaper3k di PyPI terakhir dirilis sebagai 0.2.8 pada 2018-09-28 — 2.858 hari — dan masih menarik 813.513 download per bulan. Pemeriksaan di level repo semuanya lolos; artefak yang kamu instal berumur delapan tahun. Selalu cek tanggal publish terbaru di registry secara terpisah dari log commit.

Apakah repo yang diarsipkan menyelesaikan masalah ini? GitHub menampilkan banner. Tidak selalu, dan @modelcontextprotocol/server-puppeteer menjelaskan alasannya. Field npm repository-nya null, jadi tidak ada tautan dari package ke repo yang diarsipkan dan tidak ada banner yang bisa dilewati. Yang memang diberikan npm adalah string deprecated package — "Package no longer supported" — yang dicetak saat instalasi, dan 127.232 instalasi per bulan tetap melewatinya. browserbase/mcp-server-browserbase menutup dengan benar melalui commit terakhirnya; 20.389 install-nya sebagian besar terjadi sebelum commit itu, jadi angkanya tidak banyak memberi kesimpulan ke arah mana pun.

Bagaimana cara memeriksa dependensi saya sendiri dengan cepat? Mulailah dari tanggal commit default branch, versi/tanggal upload registry, field deprecation npm, dan flag archived repositori. Lalu verifikasi atribusi package-ke-repo, cek branch non-default ketika aktivitas menyimpang, dan gunakan dependency graph atau lockfile sebelum menyebut sebuah paparan sebagai transitive. Benturan nama seperti proyek Java dan PyPI wayback yang tidak berhubungan membuat langkah eskalasi ini memang perlu.