GitHub’daki `pushed_at`, 35 scraping deposunun 14’ünü yanıltıyor; üçünde botlar doğrulandı

GitHub’ın depo sayfası, herhangi bir dala yapılan push ile değişebilen pushed_at zaman damgasını gösterir. Bu değer, varsayılan dal üzerindeki en yeni commit’ten farklı olabilir. Varsayılan dal tarihi, depo bakımına dair bir sinyaldir; paket yöneticisinin kurduğu kodu mutlaka yansıtmaz.

Paket yöneticileri normalde registry paketlerini ya da modül sürümlerini çözer. Bu yüzden bu inceleme, depo etkinliğini ve yayımlanan paketi ayrı ayrı kontrol ediyor: biri güncelken diğeri eski kalabilir.

Bu nedenle, hâlâ önerilerde görünen 35 depoyu çekip GitHub’ın başlıkta göstermediği sayıyı okudum: varsayılan daldaki en yeni commit’in tarihi.

Uyumsuzluk gerçek: 35 deponun 14’ünde pushed_at, varsayılan daldaki son commit’ten 180 günden fazla ileride görünüyor; en uç örnek 1.802 gün. Bu 14 vakanın üçünde botlar kesin olarak doğrulandı; arşivlenmiş depolar ve insan etkinliği filtrelerinden sonra, dokuz aday içinde iki doğrulanmış bot vakası kalıyor. Asıl faydalı bulgu şu: depo güncelliği ile yayımlanan artefaktın güncelliği birbirinden ayrışabiliyor.

Ne ölçüldü ve neye göre ölçüldü

Resmî referans: GitHub repository API.

Buradaki tüm sayılar, 2026-07-27 tarihinde UTC 15:44 ile 15:53 arasında alınmış canlı API yanıtlarından okundu ve önbelleğe kaydedildi. 35 satırlık veri seti, depo listesi, üretilmiş satırlar ve artifacts/ içindeki çekme/işleme betikleri, incelemenin girdilerini ve dönüşüm kodunu koruyor.

Dört veri kategorisi toplandı; registry ve etkinlik istekleri, tek tip dört çağrılık bir dizi olarak değil, ihtiyaca göre yapıldı:

• GET /repos/{owner}/{repo} — yıldız sayısı, archived, pushed_at, lisans, default_branch.
• GET /repos/{o}/{r}/commits?sha={default_branch}&per_page=1 — varsayılan daldaki en yeni commit; depo bakım sinyali olarak kullanıldı.
• GET /repos/{o}/{r}/activity?per_page=30 — bu iki değer ayrıştığında pushed_at’i gerçekte neyin değiştirdiği.
• GET /repos/{o}/{r}/releases ile PyPI ve npm registry’leri — artefaktın en son ne zaman yayımlandığı; sonuçta en çok bunu bilmek önemli oluyor.

staleness_days, varsayılan daldaki commit’ten “as-of” anına kadar geçen süredir. pushed_at ile o commit arasındaki fark ise gün cinsinden ölçülen yanılsamadır. 180 günün üzeri işaretlenir.

İki ilke özellikle belirtilmeli; çünkü sonuçları değiştirdiler.

Paket eşlemesi doğrulandı, asla varsayılmadı. README’sinde bir depodan söz eden paket, o deponun paketi değildir. Her eşlemenin yapılandırılmış bir alanla doğrulanması gerekti: ya registry’nin kendi repository/project_urls girdisi ya da depo içinde commit edilmiş bir manifest. Altı olası eşleme bu testi geçemedi; bu paketlerin indirme sayıları bilerek atfedilmedi.

Bu reddedilenlerden biri kuralın tamamını tek başına açıklıyor. curl-cffi ayda 35.763.529 indirme alıyor ve uzaktan bakınca lwthiker/curl-impersonate için Python bağı gibi görünüyor — 875 gündür soğuk bir depo. Bunu atfetmek, newspaper3k’ün sayısını kırk dört kat büyütecek ve yanlış olacaktı: curl-cffi’nin PyPI metadatası, ayrı ve aktif olarak bakımı yapılan lexiforest/curl_cffi projesini gösteriyor; bu proje en son 2026-04-03 tarihinde yayımlandı. Buradaki en çarpıcı sayı, yanlış sayıydı.

Yedinci vaka daha da tuhaf: steel-dev/steel-mcp-server, kendi package.json dosyasında @steel-dev/mcp-server tanımlıyor; fakat npm 404 döndürüyor. Hiç yayımlanmamış, dolayısıyla “hâlâ kuruluyor” ifadesi onun için doğru olamaz.

Bir sayı elde edilemiyorsa, bunu açıkça söylüyor. Go, JVM, .NET ve PHP araçlarının PyPI ya da npm varlığı yok; bu yüzden onlarda N/A (no PyPI/npm package) yazıyor — asla sıfır değil. 35 deponun 17’sinde GitHub Releases hiç yok; bu da eksik veri olarak değil, none olarak kaydedildi.

Bu alanlar kasıtlı olarak tek bir “sağlık puanı”na indirgenmedi. Eski bir varsayılan dal, güncel bir yan dal, eksik bir GitHub Release ve eski bir registry artefaktı farklı sorulara cevap verir. Satır düzeyindeki kanıtlar 35 satırlık veri setinde, depo girdileri ve üretilmiş kayıtlar ile birlikte görülebilir. Bunları, bir projenin hayatta olup olmadığına dair dört oy olarak değil, bir sonraki kontrolü belirleyen triyaj sinyalleri olarak okuyun.

Örnekleme notu, en baştan

Bu, kullanımda olduklarını sanıp aslında sürünerek ilerleyen araçlardan şüphelendiğim elle oluşturulmuş bir liste. Scraping ekosisteminin rastgele bir örneği değil; “35’in 31’i eski” ifadesi de ekosistem oranı değil — bu, benim seçme becerimin bir ölçüsüne daha yakın. İlginç sonuç eski sayısı değil. İlginç olan, bu olguyu hedefleyen bir örnek üzerinde bile test ettiğim belirli mekanizmanın vakaların yalnızca azınlığını açıklaması ve net olarak doğrulanabildiği vakaların daha da az olması.

Yanılsama gerçek ve en kötü örnek burada

sjdirect/abot, 2.308 yıldızlı bir .NET tarayıcı. GitHub, 2026-07-17 tarihinde bir push gösteriyor; bu tarih, ölçüm anından sadece on gün önce. Ancak varsayılan dalın son dokunuşu 2021-08-09 tarihinde yapılmış.

Bu, 1.802 günlük bir boşluk. Beş yıl. Başlık ise geçen haftayı söylüyor.

35 deponun 14’ünde 180 günden büyük bir fark var:

On dörtte otuz beş. Gerçek, bilinmeye değer ve onu özellikle barındıracak şekilde seçilmiş bir örneğin azınlığı.

Üç işaretli depoda botlar doğrulandı — filtre sonrası iki tane kaldı

Bu hikâyenin halk arasındaki versiyonu her zaman dependabot’u anar. Ben, işaretlenen her depo için etkinlik akışını çekip, son varsayılan dal commit’inden sonra gelen tüm referansları sınıflandırarak bunu kontrol ettim. O “sonra” kısmı önemli: son commit’ten önceki olaylar farkı neyin büyüttüğünü anlatmaz; tüm akışı saymak soruyu sessizce değiştirir.

Post-commit yöntemine göre bot kaynaklı olduğu doğrulananlar: üç. scrapinghub/splash (post-commit olayların 4’ü de dependabot/pip/* üzerinde), geziyor/geziyor (5’te 5 dependabot/go_modules/* üzerinde), apache/any23 (16’da 16 dependabot/maven/* üzerinde). Bu üçlüden biri olan any23 resmî olarak arşivlenmiş durumda; bu yüzden filtrelenmiş kümeye hiç girmiyor — geriye, diğer tüm koşulları da sağlayan iki doğrulanmış vaka kalıyor.

Açıkça yanlış: iki, ve ikisi de bot hikâyesinden daha ilginç.

dragnet-org/dragnet’teki 1.520 günlük boşluk, mp/py3.10 adlı bir dalı bir insanın push etmesinden kaynaklanıyor — birleştirilmemiş bir Python 3.10 portu. Birisi ileri taşımaya çalışmış ve sonra durmuş. Bu, zaman damgasını şişiren otomatik gürültü değil; başarısız bir kurtarma girişiminin görünür ve tarihli kaydı. Aslında veri setinin tamamındaki en faydalı sinyal bile olabilir; “bunu dependabot yaptı” çerçevesi bunu silip atardı.

Karışık ve ikisinden de büyük: iki. crawlab-team/crawlab 12.250 yıldıza sahip — örnekteki en çok yıldız alan ikinci depo — ve main üzerinde 488 günlük bir boşluk var. Akışında dependabot dalları ve insanlardan gelen, tamamı develop ve test’e yapılmış 24 post-commit push bulunuyor. Başlığı okuyan biri Şubat 2026’yı görüp sağlıklı sanır; main’e bakan biri Ekim 2024’ü görüp ölü sanır. İkisi de yanlış. Geliştirme varsayılan dalın dışına taşmış; projelerin yaptığı bir şey bu ve GitHub özet görünümü bunu ifade edemez. sjdirect/abot diğer karışık vaka: başlığı oluşturan pushed_at gerçekten dependabot kaynaklıydı; ancak bir insan 2024’te upgrade1 dalını push etti, bu yüzden daha sonra filtrelenen kümeye düşüyor.

Rhizome-Conifer/conifer belirsiz olan vaka ve başta onu yanlış okudum. Varsayılan dalı master değil, main; main ise 2023-10-12’den beri değişmemiş durumda — akıştaki tek main olayı, Ocak 2025’te bir dal oluşturma işlemi ve bu da yeniden adlandırmayla uyumlu. Öte yandan tek bir hesap, 2026-07-22 tarihinde conifer-twilight ve twilight/read-only dallarına push yaptı; bu, ölçüm tarihinden beş gün önce. Bu gerçek bir insan etkinliği, ama “aktif geliştiriliyor” demek için ref’lerin sunduğundan daha fazlası gerekir: tek katkıda bulunanın, üstelik adı read-only olan dallarda çalışması, devam eden geliştirmeden en az planlı kapanış kadar tutarlı. Burada güvenle söylenebilecek şey daha dar ama yine de önemli: 1.013 günlük fark bot gürültüsü değil ve aynı zamanda bırakılmış olmanın kanıtı da değil.

Bilinmiyor: yedi. php-html-parser, simhash-py, internetarchive/wayback, boilerpipe, waybackurls, wpull ve crawler4j doğrulanmış bir farka sahip; ancak etkinlik akışı boş dönüyor.

Cazip açıklama retention — GitHub’ın activity feed’i sonsuza kadar geriye gitmez. Önbellek, çoğu için bunu çürütüyor. Bu 123 yanıtta en eski olay 2023-03-10 tarihli ve yedinin beşinde pushed_at, bu pencerenin içinde rahatça yer alıyor: php-html-parser 2024-08-09, wpull 2024-04-29, waybackurls 2024-05-01, internetarchive/wayback 2024-03-01, simhash-py 2023-05-15. Bu zaman damgalarını neyin hareket ettirdiği akışta olmalıydı ama görünmüyor. Retention yalnızca boilerpipe (2018) ve crawler4j (2021) için açıklama getiriyor.

Dolayısıyla dürüst ifade, temiz bir açıklamadan daha dar: yedi depo için fark doğrulanmış bir gerçek, fakat nedeni kurulmuş değil — endpoint hiçbir şey döndürmedi ve bunların beşinde nedenini söyleyemem. “Bunu dependabot yaptı” ifadesi, yedinin tamamı için yalnızca bir varsayım.

Toplamda, işaretlenen 14 depo arasında:

Satırlar toplamda 14 ediyor. Bunlar pushed_at’i neyin hareket ettirdiğini sınıflandırır; bir projenin bırakılıp bırakılmadığını tek başına kanıtlamaz.

Tam filtreden geçenler ve “geçmek” ne demek

İlk iddianın dört şeyi aynı anda gerektirmesi gerekiyor: bir yıldan uzun süredir eski olmak, pushed_at’in 180 günden fazla şişmiş olması, arşivli olmamak ve bu şişmenin insan işinden kaynaklandığına dair iz olmaması. 35 adayın 9’u bu dört koşulun hepsini sağlıyor, aşağıda en önemli iki dışlama ile birlikte listeleniyor:

Bu sayının, filtrenin taşıyamayacağı bir notu var. Bu dokuzdan yalnızca ikisi — splash ve geziyor — şişmenin botlar tarafından yapıldığını olumlu kanıtlarla gösteriyor. Diğer yedisi, iki yönde de kanıt olmaması sayesinde koşulu sağlıyor. Bunlar iddiadan sağ çıkan vakalar; iddiayı doğrulayan vakalar değil. Ve tüm incelemedeki en güçlü doğrulama olan any23 — 16’da 16 dependabot olayı — depo arşivli olduğu için dışarıda kalıyor.

Ayrıca 1.802 günlük vaka abot, bu dokuzun içinde değil. Kaydında bir insan push’u bulunduğu için dördüncü koşulu geçemiyor — veri setindeki en dramatik yanılsama, gösterdiği mekanizmanın temiz bir örneği değil.

35’in 21’inde GitHub eskiyi açıkça gösterdi

Tezim için en yıkıcı bulgu buydu. 14 deponun farkı tam sıfır, yedi tanesi de 180 günün altında. 35 adayın 21’inde pushed_at, varsayılan daldaki son commit ile aynı. GitHub hiçbir şeyi gizlemiyor.

Örnekteki en ölü görünenlerden bazıları da dahil:

BuilderIO/gpt-crawler’ın 22.374 yıldızı var ve başlığı 2025-07-07 tarihinden beri aynı şeyi söylüyor. Hiçbir şey gizlenmiyor ve kurulum hacmi devam ediyor.

Bu, iddiayı daha dar bir yere itiyor: GitHub, vakaların azınlığında eskiyi gizliyor; çoğunlukta ise açıkça söylüyor ve kurulumlar yine de devam ediyor. Neden devam ettikleri bu verinin cevaplayabileceği bir şey değil — buradaki sayılar kurulumları, kararları değil, sayıyor. Ama bu ikinci gruba yönelik herhangi bir arayüz değişikliği bir işe yaramaz; çünkü bu grup daha büyük olan grup.

Depo etkinliği ile yayımlanan artefaktlar ayrışabiliyor

Veri setindeki tek bir satır, çerçeveyi tamamen kırıyor.

codelucas/newspaper — 15.126 yıldız — aktif. Varsayılan daldaki son commit’i 2026-07-21 tarihli; ölçüm tarihi 2026-07-27’ye göre yalnızca altı gün önce ve bakımcı tarafından yazılmış. Depo düzeyindeki tüm kontroller geçiyor.

Herkesin kurduğu paket ise newspaper3k 0.2.8; yayımlanma tarihi 2018-09-28. Bu, 2.858 gün önceydi ve ayda 813.513 indirme çekiyor.

Varsayılan dal güncel, ancak PyPI artefaktı 2018’den beri yayımlanmamış. Bu, bir sürüm boşluğunu kanıtlar; neden yayımlanmadığını ya da hattın bozuk olup olmadığını değil. Bu, yalnızca depoya bakarak yapılan bir bakım kontrolünün kaçıracağı türden bir risk; çünkü pip install newspaper3k sonrası normalde çalışan şey registry artefaktıdır.

Paketlere, depo yerine bakınca desen her yerde görülüyor. Eşlemesi doğrulanmış 17 paketin içinde 16’sı bir yıldan uzun süre önce yayımlanmış, ve bu 16 paket toplam 2,30 milyon kurulumun yaklaşık 2,28 milyonunu oluşturuyor:

tls-client ayrı bir satırı hak ediyor: 905 gündür soğuk bir depodan ayda 790.305 kurulum alıyor; güncel kalmanın işin tamamı olduğu bir kategoride. Tarayıcı TLS davranışı değişir; 2024’ün başında bunu takip etmeyi bırakan bir kütüphane, 2024 başı varsayımlarıyla çalışıyor demektir.

Bu tablo için iki uyarı. Registry indirme sayıları CI çalıştırmalarını ve aynaları da içerir; hiçbir şeyi tekilleştirmez. Dolayısıyla kullanıcıyı değil, kurulum hacmini ölçer. Ayrıca kayan pencerelerin bitiş tarihi aynı değil — npm’nin penceresi 2026-07-24’e yakın, pypistats’inkiler çekim zamanına göre hesaplanıyor — bu nedenle toplam, hafifçe kaymış ayların toplamıdır ve “yaklaşık 2,28 milyon” diye okunmalıdır; rakamın tam basamağına kadar değil.

Bilinmesi gereken isim çakışması

internetarchive/wayback, 1.916 gündür soğuk olan eski Java OpenWayback’tir. PyPI’daki wayback ise tamamen farklı bir proje — edgi-govdata-archiving/wayback — ve sağlıklıdır; 2026-06-19 tarihinde 0.5.1 sürümünü yayımlamış, yani ölçüm tarihinden beş hafta önce. Aynı isim, zıt durum, ilişki yok. Bu, reddedilen altı eşlemeden biriydi ve gerçek bir kullanıcıyı en çok ısırma ihtimali olanı da bu: ismi aradığınızda ikisi de çıkar ve sayfalardan hiçbiri hangisini bulduğunuzu söylemez.

Arşivli, kullanımdan kaldırılmış ve ayda hâlâ 127.232 kez kuruluyor

Örneklemdeki altı depo archived: true taşıyor; GitHub bunu tam genişlikte bir bant olarak gösteriyor. İlk yorumum, insanların gürültülü uyarıları görmezden geldiği yönündeydi. Önbellek ise hikâyenin bundan daha kötü olduğunu söylüyor.

Resmî referans: npm download-count API documentation.

Resmî referans: npm'in deprecation belgeleri.

@modelcontextprotocol/server-puppeteer, modelcontextprotocol/servers-archived içinden ayda 127.232 kurulum çekiyor. Ancak npm repository alanı null — paket sayfasından depoya geri giden bir bağlantı yok; yani kurulum yapan kişinin atlayıp geçtiği bir arşiv bandı da yok. Bu paketi çeken çoğu kişinin, oraya giden bir yolu hiç olmamış.

npm’nin gerçekten yayımladığı şey ise kullanımdan kaldırma bilgisidir. Paketin en son sürümü deprecated: "Package no longer supported. Contact Support at https://www.npmjs.com/support for more info." taşıyor — npm bunu kurulum sırasında terminale yazdırıyor. Yani uyarı, kullanıcının bulunduğu yerde iletiliyor ve buna rağmen ayda 127.232 kurulum gerçekleşiyor. Bu, banner bulgusundan daha güçlü ve başka bir noktaya işaret ediyor: sinyal eksik değil, yalnızca kimsenin okumak zorunda olmadığı bir kurulum çıktısı duvarının içine geliyor.

browserbase/mcp-server-browserbase, temiz bir kapanışın nasıl göründüğünü gösteriyor: son varsayılan dal commit’i, 2026-07-20 tarihinde, kelimenin tam anlamıyla “Mark repository as archived and unmaintained (#198)”. Bakımcılar bunu ilan etmiş, tarih atmış ve API’de işaretlemiş. Yine de 20.389 kurulumunu dikkatle okumak gerekir — npm penceresi 2026-06-25 ile 2026-07-24 arasında, yani bu 30 günün 26’sı arşiv commit’inden önce. Bu sayı çoğunlukla duyuru öncesi talebi gösteriyor, karara meydan okumayı değil. Sonrasında ne olduğu bu kesitten gerçekten bilinmiyor; herhangi bir şey söylemek için bir ay sonra tekrar bakmak isterdim.

57 yıldız, ayda 204.025 kurulum

Janpot/microdata-node’un 57 yıldızı var ve 2020-05-11 tarihli bir sürümden ayda 204.025 indirme alıyor.

57 yıldızla microdata-node, registry hacmine kıyasla oldukça düşük depo görünürlüğüne sahip. Kurulum-yıldız oranı 3.579:1; bu, dolaylı kullanım, CI tekrarları, aynalar ya da doğrudan makine tüketimiyle uyumlu. Bu inceleme bağımlılık grafiği çekmediği için bu açıklamalar arasında seçim yapamaz.

Bu satır, dolaylı maruziyeti envantere almanız için bir işaret; ancak transitive kullanım kanıtı, bu incelemenin toplamış olmadığı ters bağımlılık ya da lockfile kanıtı gerektirir.

Eski olmak, bozuk olmakla aynı şey değildir

Dürüst bir incelemenin şunu söylemesi gerekir: buradaki hiçbir şeyin çalışıp çalışmadığını test etmiyor. Sadece birinin hâlâ içeride olup olmadığını ölçüyor.

Bunların bazıları sadece işini bitirmiş. SetSimilaritySearch, küme-benzerliği algoritmaları uygular; bunlar çürümez. simhash, 2007 tarihli bir makaledir. boilerpipe’ın içerik çıkarma algoritması 2026’da da 2015’teki gibi davranır — modern sayfalara karşı doğruluğu ne olursa olsun, kod sizin altınızdan kayıp gitmiyor.

Çürüyen şey, öbür uçta hareketli bir hedefi olan her şeydir:

• Tarayıcı otomasyonu — Chrome’un her sürümü onu bozabilir.
• Tarayıcı davranışını taklit eden HTTP istemcileri — tarayıcılar değişir ve sabitlenmiş bir kütüphane onlarla uyuşmaz; tls-client burada duruyor.
• Siteye özel ayrıştırıcılar ve site bazlı çıkarım kuralları — her site tasarımı değişikliği bir bug’dır.
• Üçüncü taraf API saran her şey — sağlayıcı şemayı değiştirir ve siz bunu üretimde öğrenirsiniz.
• Bir LLM saran her şey — model kullanımdan kaldırmaları bunların hepsinden hızlı hareket eder.

Dolayısıyla “1.606 gündür eski” ifadesi bir kategori için alarm zili, bir karma değerleme aracı içinse neredeyse önemsiz olabilir. Burada hiçbir bozulma testi yapılmadı ve böyle bir iddia da öne sürülmüyor; kendi bağımlılıklarını kategorilerine göre sıralamak size hiçbir şey kaybettirmez ve yalnızca eski olma sayısından daha fazla fayda sağlar.

Soruyu gerçekten yanıtlayan dört kontrol

Bunların hiçbiri depo başlığı değil.

1, 2 ve 3 numaralı kontrolleri hızlı triyaj olarak çalıştırın. Ardından depo metadatası yoksa, paket eşlemesi belirsizse, etkinlik varsayılan olmayan bir dala taşındıysa ya da registry artefaktı depodan ayrışıyorsa daha derine inin. Kimlik doğrulaması yapılmamış GitHub limitleri ve registry gecikmesi, “bir saniyede garanti” vaat etmeyi uygunsuz kılar.

Eğer bir kontrol, hareket eden bir kategoride soğuk bir şey ortaya çıkarırsa, bu alandaki bakımı sürdürülen alternatifler kendi testlerimizde belgelenmiş durumda: dragnet ve boilerpipe’ın yaptığı içerik çıkarımı için Trafilatura, tarama çerçeveleri için Scrapy veya Crawlee, LLM odaklı çıkarım için Crawl4AI ve Firecrawl, dayanıklılığın önemli olduğu yerlerde ise Scrapling. Bizim açık kaynak scraper sütunu daha geniş kümeyi izliyor. Bunlar birinci taraf incelemeler; bizimkiler de dahil, herhangi bir öneriye güvenmeden önce dört kontrolü kendiniz çalıştırın.

Bu verinin sınırları

• Örnek seçimi. Bırakılmış olabileceğinden şüphelenilen projeler elle seçildi. Bundan ekosistem oranı çıkarılamaz.
• Bozulma testi yok. Bu 35 araçtan hiçbiri canlı bir site üzerinde çalıştırılmadı. Eski olmak bakım sinyalidir, işlevsel hüküm değil.
• İndirme sayıları makineleri de içerir. CI, aynalar, tekilleştirme yok ve bitiş tarihleri aynı olmayan pencereler. Kullanıcı değil, kurulum hacmi; kararlar değil.
• Yedi bilinmeyen neden bilinmiyor. Etkinlik akışı hiçbir şey döndürmedi ve yedinin beşinde retention bunu açıklamıyor. Hücreyi boş bırakmak, onu popüler tahminle doldurmaktan iyidir.
• staleness_days, commit tarihi kullanır. Yeniden yazılmış ya da geriye çekilmiş tarih, sonucu bozar. Böyle bir durum saptanmadı; bu, olmadığı anlamına gelmez.
• Tek bir as-of tarihi. 2026-07-27. Bu depoların bir kısmı siz okurken çoktan değişmiş olabilir — özellikle newspaper düzenli commit alıyor. Dört kontrolü yeniden çalıştırın; benim tarihlerimi alıntılamayın.

Yönetilen bir hizmet bunun şeklini nasıl değiştirir

Buradaki her kontrolün var olma nedeni şu: self-hosted bir kütüphanede eski kalma sorumluluğu size aittir. Sabitlenmiş bir HTTP istemcisi güncel bir tarayıcı gibi davranmayı bırakırsa, bu sizin olayıdır; hangi saatte ortaya çıkarsa çıksın.

Yazar notu: Thunderbit bizim yönetilen scraping ürünümüzdür. Yönetilen bir hizmet, bakım sorumluluğunun bir kısmını satıcıya aktarır; ancak kapsama alanı, yanıt süresi, bağımlılık riski ve satıcı sürekliliği risk modelinin bir parçası olur. Thunderbit bu depo incelemesinde değerlendirilmedi.

Dürüst takas şudur: kaynak kodu okuma, sürümü sabitleme ve gece 2’de sorunu kendin çözme özgürlüğünün bir kısmından vazgeçersin. Zaten scraper bakımını üstlenen bir ekip için açık kaynak yolu çoğu zaman doğru tercihtir — dört kontrol, bunu varsayım değil karar haline getirmenin yoludur.

Web Veri Çıkarmak için Thunderbit’i Deneyin

Kısa versiyon

GitHub’ın bırakılmış projeleri gizlediğini kanıtlamak için bir liste hazırladım. Yanılsama 35 deponun 14’ünde gerçek ve bir örnekte çarpıcı: sjdirect/abot, 2021’den beri donmuş bir varsayılan dala karşı geçen hafta yapılmış bir push gösteriyor; 1.802 günlük fark.

Ama mekanizma, hikâyeden daha dar. Dokuz depo, iddianın gerektirdiği tüm koşulları sağlıyor ve bu dokuzun yalnızca ikisi — splash ve geziyor — şişmeyi botların yaptığına dair olumlu kanıt sunuyor; geri kalanlar yalnızca kanıt yokluğu sayesinde geçiyor. İşaretlenen iki depoda insanlar bir projeyi canlandırmaya çalışıp başarısız olmuş. Biri olan crawlab, 12.250 yıldıza sahip ve geliştirmeyi develop dalına taşımış. Yedi vakada etkinlik akışı boş döndü; bunların beşinde retention açıklama getirmiyor, bu yüzden neden varsayılmıyor, kurulmamış kalıyor. Ve 35 deponun 21’inde GitHub eskiyi doğru biçimde raporladı.

Veri setindeki en kötü örnek, tüm depo düzeyi kontrolleri geçiyor. codelucas/newspaper 2026-07-21 tarihinde commit edildi; son kez 2018-09-28’de yayımlanan newspaper3k, o ay 813.513 kez indirildi. Örnek boyunca, sürümü bir yıldan eski olan 16 paket ayda yaklaşık 2,28 milyon kurulum oluşturuyor.

İlk triyaj için varsayılan dal commit tarihini, registry sürüm/yükleme tarihini, arşivli bayrağını ve npm deprecation alanını kontrol edin. Sonuca varmadan önce paket-depo eşlemesini ve varsayılan olmayan dal geliştirmesini doğrulayın.

Web Veri Çıkarmak için Thunderbit’i Deneyin Get Started Free

SSS

pushed_at nedir ve neden “son güncelleme” anlamına gelmez?
pushed_at, GitHub API’de depo sayfasındaki etkinlik zaman damgasının arkasındaki alandır ve herhangi bir dala push yapıldığında güncellenir. Varsayılan daldaki en yeni commit, depo bakımına dair sinyallerden yalnızca biridir; paket yöneticileri ise normalde registry artefaktlarını veya çözümlenmiş modül sürümlerini kurar. Bu incelemede 35 deponun 14’ünde iki GitHub tarihi 180 günden fazla ayrıştı.

Bu zaman damgasını hep dependabot mu şişiriyor?
Hayır; halk arasındaki hikâyenin en zayıf yanı da buydu. Yalnızca son varsayılan dal commit’inden sonra gerçekleşen olaylar sayıldığında, işaretlenen 14 deponun 3’ünde botlar doğrulandı (splash 4’te 4, geziyor 5’te 5, any23 16’da 16). 2 vakada açıkça yanlış çıktı: dragnet’teki fark, bir insanın birleştirilmemiş Python 3.10 portunu push etmesinden geliyor. İki vaka daha karışık; bunlardan biri crawlab, burada 24 insan push’u develop ve test dallarına giderken main yerinde saydı. Yedi vakada ise etkinlik akışı hiç bir şey döndürmedi; bu yüzden neden kurulmamış durumda — retention bu yedinin yalnızca ikisini açıklıyor.

Eski bir depo, aracın bozuk olduğu anlamına mı gelir?
Bu kanıta göre hayır — burada hiçbir araç canlı bir site üzerinde çalıştırılmadı. Eski olmanın önemi, hedefin ne kadar hızlı değiştiğine bağlıdır: tarayıcı otomasyonu, tarayıcı davranışını taklit eden HTTP istemcileri, siteye özgü ayrıştırıcılar ve API/LLM sarmalayıcıları hızla yaşlanır; buna karşılık SetSimilaritySearch veya simhash gibi algoritmik kütüphaneler yıllarca eski kalıp yine de sorunsuz olabilir. tls-client, örnekteki en keskin vakadır: 905 gündür soğuk bir depodan ayda 790.305 kurulum.

Bir depo aktifken paket nasıl ölü kalabilir?
Bu codelucas/newspaper örneği ve incelemenin bulduğu en önemli şey bu. Varsayılan dalı 2026-07-21’de commit edilmiş; bu, ölçüm tarihinden günler önce. Ancak PyPI’daki newspaper3k, son kez 2018-09-28’de 0.2.8 sürümüyle yayımlandı — 2.858 gün önce — ve hâlâ ayda 813.513 indirme alıyor. Depo düzeyi kontrollerin hepsi geçiyor; ancak kurduğunuz artefakt sekiz yıllık. Registry’nin son yayımlanma tarihini commit log’undan ayrı kontrol edin.

Arşivlenmiş depolar bu sorunu çözer mi? GitHub bir bant gösteriyor.
Güvenilir şekilde değil; @modelcontextprotocol/server-puppeteer nedenini gösteriyor. npm repository alanı null, yani paket sayfasından arşivli depoya giden bağlantı yok ve atlanacak bir bant da yok. npm’nin gerçekten verdiği şey paketin deprecated metni — “Package no longer supported” — kurulum sırasında yazdırılıyor ve ayda 127.232 kurulum buna rağmen devam ediyor. browserbase/mcp-server-browserbase, kapanışını son commit’inde düzgün biçimde duyurdu; 20.389 kurulumunun çoğu bu commit’ten önce gerçekleştiği için durum hakkında çok az şey söylüyor.

Kendi bağımlılıklarımı hızlıca nasıl kontrol ederim?
Varsayılan dal commit tarihinden, registry sürüm/yükleme tarihinden, npm deprecation alanından ve depo archived bayrağından başlayın. Ardından paket-depo eşlemesini doğrulayın, etkinlik varsayılan olmayan dallara kaydıysa onları inceleyin ve maruziyeti transitive diye adlandırmadan önce dependency graph ya da lockfile kullanın. Bağlantısız Java ve PyPI wayback projeleri gibi isim çakışmaları bu ikinci aşamayı zorunlu kılar.