GitHub `pushed_at` vilseledde i 14 av 35 granskade scraping-repositorier; bots bekräftades i tre

GitHubs reposida visar pushed_at, en tidsstämpel som kan uppdateras när vilken gren som helst får en push. Den kan därför skilja sig från det senaste committet på default-grenen. Datumet för default-grenen är en signal om hur aktivt ett repo underhålls; det är inte nödvändigtvis den kod som en pakethanterare installerar.

Pakethanterare hämtar normalt registry-artifakter eller modulspecifika versioner. Därför granskar den här genomgången repoaktivitet och publicerad artefakt var för sig: endera kan vara aktuell medan den andra redan är föråldrad.

Så jag plockade ut 35 repos som fortfarande dyker upp i rekommendationer och läste av siffran GitHub inte visar i rubriken: datumet för det senaste committet på default-grenen.

Skillnaden är verklig: 14 av de 35 har ett pushed_at som ligger mer än 180 dagar före det senaste committet på default-grenen, med en topp på 1 802 dagar. I tre av dessa 14 har bots bekräftats; efter filtrering för arkiverade repos och mänsklig aktivitet återstår två bekräftade botfall bland nio kandidater. Den mer användbara slutsatsen är att aktualiteten för repo och publicerad artefakt kan glida isär.

Vad som mättes, och hur

Officiell referens: GitHub repository API.

Varje siffra här är avläst från ett live-API-svar mellan 15:44 och 15:53 UTC den 2026-07-27 och cachelagrad. 35-radersdatasetet, repolistan, de byggda raderna samt hämtnings- och byggskripten i artifacts/ bevarar både underlag och transformationskod.

Fyra datakategorier samlades in; registry- och aktivitetsanrop gjordes villkorat, inte som en enhetlig fyranropssekvens:

• GET /repos/{owner}/{repo} — stjärnor, archived, pushed_at, licens, default_branch.
• GET /repos/{o}/{r}/commits?sha={default_branch}&per_page=1 — senaste committet på default-grenen, använt som signal för repo-underhåll.
• GET /repos/{o}/{r}/activity?per_page=30 — för varje repo där de två ovan skiljer sig åt, vad som faktiskt flyttade pushed_at.
• GET /repos/{o}/{r}/releases plus PyPI- och npm-registren — när artefakten senast släpptes, vilket visar sig spela större roll än båda andra.

staleness_days är tiden som förflutit från default-grenens commit till referenstidpunkten. Skillnaden mellan pushed_at och det committet är illusionen, mätt i dagar. Allt över 180 dagar flaggas.

Två principer är värda att nämna eftersom de ändrade utfallet.

Pakettilldelning verifierades, aldrig antogs. Att ett repo nämns i en README betyder inte att det är paketets repo. Varje koppling måste bekräftas via ett strukturerat fält — antingen registryns egna repository-/project_urls-uppgift eller ett manifest som checkats in i repot. Sex troliga kopplingar föll på det testet och deras nedladdningssiffror är därför medvetet inte tilldelade.

Ett av de avslagen räcker för att motivera regeln. curl-cffi drar 35 763 529 nedladdningar i månaden och ser på avstånd ut som Python-bindningen till lwthiker/curl-impersonate — ett repo som varit kallt i 875 dagar. Om det hade tilldelats skulle siffran blivit fyrtiofyra gånger större än newspaper3k-siffran, och det hade varit fel: curl-cffis egen PyPI-metadatam pekar på lexiforest/curl_cffi, ett separat och aktivt projekt som senast släpptes 2026-04-03. Den mest spektakulära siffran här var alltså den felaktiga.

Ett sjunde fall är märkligare: steel-dev/steel-mcp-server deklarerar @steel-dev/mcp-server i sin egen package.json, men npm svarar 404. Det har aldrig publicerats, så att det ”fortfarande installeras” kan inte vara sant alls.

När en siffra inte gick att få fram, står det uttryckligen. Go-, JVM-, .NET- och PHP-verktyg saknar PyPI- eller npm-närvaro, så de får N/A (no PyPI/npm package) — aldrig noll. Sjutton av de 35 har inga GitHub Releases alls; det registreras som none, inte som saknad data.

De här fälten slås medvetet inte ihop till ett enda ”hälsopoäng”. En föråldrad default-gren, en färsk sidogren, en saknad GitHub Release och en gammal registry-artefakt svarar på olika frågor. Radnivåbevisen finns i 35-radersdatasetet, med repository-underlagen och de byggda posterna bredvid. Läs dem som triage-signaler som avgör nästa kontroll, inte som fyra omröstningar om huruvida ett projekt lever.

Urvalsreservationen, direkt från början

Det här är en handgjord lista över verktyg som jag misstänkte levde på sitt rykte. Det är inte ett slumpmässigt urval av scraping-ekosystemet, och ”31 av 35 är föråldrade” är inte en ekosystemsiffra — det är nära nog ett mått på hur väl jag valde ut fallen. Den intressanta slutsatsen är inte antalet föråldrade. Det intressanta är att även i ett urval som valts för just fenomenet förklarade den mekanism jag testade bara en minoritet av fallen, och kunde bekräftas positivt i ännu färre.

Illusionen är verklig, och det här är värstafallet

sjdirect/abot, en .NET-crawler med 2 308 stjärnor. GitHub rapporterar en push den 2026-07-17, tio dagar före referenstidpunkten. Default-grenen ändrades senast 2021-08-09.

Det är en lucka på 1 802 dagar. Fem år. Rubriken säger förra veckan.

Fjorton av de 35 repona visar en lucka på över 180 dagar:

Fjorton av trettiofem. Verkligt, värt att känna till, och en minoritet av ett urval som valts just för att innehålla det.

Bots bekräftas i tre flaggade repos — och två återstår efter filtrering

Den folkliga versionen av den här historien nämner alltid dependabot. Jag kontrollerade det genom att hämta aktivitetsflödet för varje flaggat repo och klassificera varje ref som pushats efter det senaste committet på default-grenen. Det där ”efter” är viktigt: event före senaste commit säger inget om vad som blåste upp luckan, och att räkna hela flödet ändrar tyst frågan.

Bekräftat botdrivet, enligt metoden efter commit: tre. scrapinghub/splash (4 av 4 post-commit-events på dependabot/pip/*), geziyor/geziyor (5 av 5 på dependabot/go_modules/*), apache/any23 (16 av 16 på dependabot/maven/*). Ett av de tre, any23, är formellt arkiverat, så det kommer aldrig in i den filtrerade mängden — kvar blir två bekräftade fall som också uppfyller alla andra villkor.

Helt fel: två, och båda är mer intressanta än botberättelsen.

dragnet-org/dragnets lucka på 1 520 dagar kommer från att en människa pushade en gren som heter mp/py3.10 — en omergad portning till Python 3.10. Någon försökte föra den framåt och slutade. Det är inte automatiskt brus som blåser upp en tidsstämpel; det är en synlig, daterad notering om ett räddningsförsök som misslyckades. Det är kanske den mest användbara signalen i hela datasetet, och ”det var dependabot” hade suddat ut den.

Blandad, och större än båda andra: två. crawlab-team/crawlab har 12 250 stjärnor — den näst mest stjärnmärkta reposidan i urvalet — och en lucka på 488 dagar på main. Flödet innehåller dependabot-grenar och 24 post-commit-pushar från människor, alla till develop och test. En användare som bara läser rubriken ser februari 2026 och antar att allt är friskt; en användare som bara tittar på main ser oktober 2024 och antar att det är dött. Båda har fel. Utvecklingen flyttade bort från default-grenen, vilket är något projekt gör och som GitHubs sammanfattningsvy inte kan uttrycka. sjdirect/abot är det andra blandfallet: pushen som satte rubrikens pushed_at var faktiskt dependabot, men en människa pushade upgrade1 2024, vilket är varför den senare faller bort ur den filtrerade mängden.

Rhizome-Conifer/conifer är det tvetydiga fallet, och jag läste det först fel. Default-grenen är main, inte master, och main har varit still sedan 2023-10-12 — det enda main-eventet i flödet är en branchskapelse i januari 2025, vilket stämmer med en omdöpning. Samtidigt pushade ett enda konto till conifer-twilight och twilight/read-only den 2026-07-22, fem dagar före referenstidpunkten. Det är genuin mänsklig aktivitet, men ”aktivt utvecklad” är mer än vad refs visar: en enda medverkande, på grenar med namnet read-only, passar minst lika bra med en kontrollerad avveckling som med pågående utveckling. Det man säkert kan säga är snävare men fortfarande värt att säga: luckan på 1 013 dagar är inte botbrus, men den är inte heller bevis för övergivande.

Okänt: sju. php-html-parser, simhash-py, internetarchive/wayback, boilerpipe, waybackurls, wpull och crawler4j har alla en verifierad lucka och ett aktivitetsflöde som kommer tillbaka tomt.

Den frestande förklaringen är retention — GitHubs aktivitetsflöde sträcker sig inte tillbaka hur långt som helst. Cachen motsäger det för de flesta av dem. Det äldsta eventet i någon av dessa 123 svar är 2023-03-10, och fem av de sju har ett pushed_at som ligger bekvämt inom det fönstret: php-html-parser 2024-08-09, wpull 2024-04-29, waybackurls 2024-05-01, internetarchive/wayback 2024-03-01, simhash-py 2023-05-15. Det som flyttade de tidsstämplarna borde ha funnits i flödet men gjorde inte det. Retention förklarar bara boilerpipe (2018) och crawler4j (2021).

Så den ärliga formuleringen är smalare än en snygg förklaring: för sju repos är luckan ett verifierat faktum och orsaken är inte fastställd — endpointen gav inget svar, och för fem av dem kan jag inte säga varför. ”Det var dependabot” är ett antagande i alla sju fall.

Summerat över de 14 flaggade reporna:

Raderna summerar till 14. De klassificerar vad som flyttade pushed_at; de avgör inte oberoende om ett projekt är övergivet.

Vad som överlever hela filtret, och vad ”överlever” betyder

Det ursprungliga påståendet kräver fyra saker samtidigt: föråldrat med över ett år, pushed_at uppblåst med mer än 180 dagar, inte arkiverat, och inga tecken på att uppblåsningen kom från mänskligt arbete. Nio av 35 kandidater klarar alla fyra, listade här tillsammans med de två viktigaste undantagen:

Den siffran behöver en kvalificering som filtret inte kan bära. Endast två av de nio — splash och geziyor — har positiv bevisning för att bots drev upp siffran. De andra sju klarar det fjärde villkoret genom att det saknas bevis åt båda håll. De är fall där påståendet överlever, inte fall som bekräftar det. Och den starkaste enskilda bekräftelsen i hela granskningen, any23 med 16 av 16 dependabot-event, faller bort eftersom repot är arkiverat.

Notera också att abot, fallet med 1 802 dagar, inte finns bland de nio. Dess historik innehåller en mänsklig push, så den missar det fjärde villkoret — den mest dramatiska illusionen i datasetet är alltså inte ett rent exempel på mekanismen den illustrerar.

För 21 av 35 rapporterade GitHub föråldringen korrekt

Här är slutsatsen som gjorde störst skada på min tes. Fjorton repos har en lucka på exakt noll, och sju till ligger under 180 dagar. För 21 av 35 kandidater är pushed_at samma som det senaste committet på default-grenen. GitHub döljer alltså inte allt.

Även bland några av de mest döda sakerna i urvalet:

BuilderIO/gpt-crawler har 22 374 stjärnor och dess rubrik har sagt samma sak sedan 2025-07-07. Inget är dolt, och installationsvolymen fortsätter.

Det tvingar ner påståendet till något smalare: GitHub döljer föråldring i en minoritet av fallen, och i majoriteten säger den det rakt ut medan installationerna fortsätter ändå. Varför de fortsätter ligger utanför vad den här datan kan besvara — siffrorna här räknar installationer, inte beslut. Men ingen UI-ändring löser den andra gruppen, som dessutom är den större.

Repoaktivitet och publicerade artefakter kan gå åt olika håll

Den enskilt mest slående raden i datasetet bryter hela ramen.

codelucas/newspaper — 15 126 stjärnor — är aktivt. Dess senaste commit på default-grenen är daterat 2026-07-21, mot referenstidpunkten 2026-07-27, och det skrevs av underhållaren. Alla kontroller på repo-nivå passerar.

Paketet som alla installerar är newspaper3k 0.2.8, publicerat 2018-09-28. Det är 2 858 dagar gammalt och drar 813 513 nedladdningar i månaden.

Default-grenen är aktuell, medan PyPI-artefakten inte har släppts sedan 2018. Det här bevisar ett releasespann, inte varför paketet inte släpps eller om en pipeline är trasig. Det är den typen av risk som en kontroll som bara tittar på repo hade missat, eftersom det är registry-artefakten som normalt körs efter pip install newspaper3k.

När man tittar på paket i stället för repos blir mönstret överallt. Bland de 17 paket vars repokoppling verifierades, har 16 senast släppts för mer än ett år sedan, och dessa 16 står för ungefär 2,28 miljoner installationer i månaden av totalt 2,30 miljoner:

tls-client förtjänar en egen rad: 790 305 installationer i månaden från ett repo som varit kallt i 905 dagar, i en kategori där det att hålla sig aktuell är hela uppgiften. TLS-beteendet i webbläsare ändras; ett bibliotek som slutade följa det i början av 2024 kör på antaganden från tidigt 2024.

Två förbehåll om tabellen. Registry-nedladdningar inkluderar CI-körningar och speglar och deduplicerar ingenting, så de mäter installationsvolym, inte människor. Och de rullande fönstren har inte samma slutdatum — npm:s ligger nära 2026-07-24, pypistats är relativa till hämtningstidpunkten — så totalsumman är en summering av månader som ligger lite förskjutna och bör läsas som ”ungefär 2,28 miljoner”, inte på sista decimalen.

Namnkollisionen som är värd att känna till

internetarchive/wayback är den döda Java OpenWayback, kallad i 1 916 dagar. wayback på PyPI är ett helt annat projekt — edgi-govdata-archiving/wayback — och det mår bra, med version 0.5.1 släppt den 2026-06-19, fem veckor före referenstidpunkten. Samma namn, motsatt läge, ingen koppling. Det här var ett av de sex avslagna attribueringsfallen, och det är det som sannolikt kan slå mot en riktig användare: söker du på namnet får du båda, och ingenting på någon av sidorna säger vilken du faktiskt hittade.

Arkiverat, avvecklat och ändå installerat 127 232 gånger i månaden

Sex repos i urvalet har archived: true, vilket GitHub visar som en fullbredds-banner. Min första läsning var att det bevisar att folk ignorerar högljudda varningar. Cachen säger att historien är värre än så.

Officiell referens: npm download-count API documentation.

Officiell referens: npm:s dokumentation om deprecation.

@modelcontextprotocol/server-puppeteer drar 127 232 installationer i månaden från modelcontextprotocol/servers-archived. Men dess npm-fält repository är null — det finns ingen länk från paketsidan tillbaka till repot, så bannern är inget en installatör bara kunde hoppa över. De flesta som hämtar det här paketet har aldrig ens haft vägen dit.

Det npm faktiskt publicerar är avvecklingen. Paketets senaste version har deprecated: "Package no longer supported. Contact Support at https://www.npmjs.com/support for more info." — vilket npm skriver ut i terminalen vid installation. Så varningen levereras, på plats där användaren faktiskt befinner sig, och ändå fortsätter 127 232 installationer i månaden. Det är en starkare slutsats än bannerfrågan, och den pekar åt ett annat håll: signalen saknas inte, den kommer in i en vägg av installationsutskrift som ingen tvingas läsa.

browserbase/mcp-server-browserbase visar hur en snygg avveckling ser ut: dess sista commit på default-grenen, den 2026-07-20, är bokstavligen "Mark repository as archived and unmaintained (#198)". Underhållarna meddelade det, tidsatte det och markerade det i API:t. Dess 20 389 installationer är ändå värda att läsa noggrant — npm-fönstret sträcker sig från 2026-06-25 till 2026-07-24, så 26 av dessa 30 dagar föregår arkiveringscommittet. Siffran speglar alltså mest efterfrågan före beskedet, inte motstånd mot det. Vad som händer sedan går inte att avgöra från den här ögonblicksbilden, och jag skulle vilja se en ny avläsning en månad senare innan jag drar några långtgående slutsatser.

57 stjärnor, 204 025 installationer i månaden

Janpot/microdata-node har 57 stjärnor och drar 204 025 nedladdningar i månaden från en release daterad 2020-05-11.

Med 57 stjärnor har microdata-node mycket låg repo-synlighet i förhållande till sin registry-volym. Installations-till-stjärnratio på 3 579 till 1 stämmer med indirekt användning, upprepade CI-körningar, speglar eller direkt maskinanvändning. Den här granskningen hämtade inga beroendegrafer och kan därför inte välja mellan de förklaringarna.

Raden är en signal om att inventera indirekt exponering, men att bevisa transitiv användning kräver reverse-dependency- eller lockfile-bevis, vilket den här granskningen inte samlade in.

Föråldrat är inte samma sak som trasigt

En ärlig granskning måste säga detta: inget av detta mäter om något faktiskt är trasigt. Det mäter om någon är hemma.

En del av detta är helt enkelt färdigt. SetSimilaritySearch implementerar algoritmer för setsimilaritet; de blir inte ”dåliga” av ålder. simhash bygger på en artikel från 2007. boilerpipes innehållsextraktion fungerar 2026 på samma sätt som 2015 — oavsett hur bra den är mot moderna sidor har koden inte drivit iväg under dig.

Det som åldras är allt som har ett rörligt mål i andra änden:

• Webbläsarautomatisering — varje Chrome-version kan bryta den.
• HTTP-klientbeteende som efterliknar riktiga webbläsare — webbläsare ändras, och ett fruset bibliotek slutar matcha; tls-client hör hemma här.
• Platsspecifika parsers och extraktionsregler per webbplats — varje redesign är ett fel.
• Allt som wrappar ett tredjeparts-API — leverantören ändrar schemat och du märker det i produktion.
• Allt som wrappar en LLM — modellavvecklingar går snabbare än något av det här.

Så ”1 606 dagar föråldrat” är en femalarmshändelse för en kategori och nästan irrelevant för ett hashing-verktyg. Inget av detta testade faktisk funktion och inget påstående görs om det; att sortera dina egna beroenden efter vilken kategori de tillhör kostar inget och hjälper mer än staleness-siffran ensam.

De fyra kontroller som faktiskt besvarar frågan

Ingen av dem är repo-rubriken.

Kör kontrollerna 1, 2 och 3 som snabb triage. Eskalera sedan när repo-metadata saknas, paketattribueringen är oklar, aktiviteten har flyttat till en icke-default-gren eller registry-artefakten avviker från repot. Oauth-lösningar och registryfördröjning gör ett löfte om en sekund olämpligt.

Om en kontroll hittar något kallt i en kategori som rör sig, finns de underhållna alternativen i det här området dokumenterade i vår egen testning: Trafilatura för innehållsextraktionen som dragnet och boilerpipe brukade göra, Scrapy eller Crawlee för crawler-ramverk, Crawl4AI och Firecrawl för LLM-orienterad extraktion, samt Scrapling där robusthet spelar roll. Vår open-source scraper-pelare täcker det bredare fältet. Det är förstahandsgranskningar; kör själv de fyra kontrollerna innan du litar på någon rekommendation, inklusive vår.

Begränsningar i den här datan

• Urvalet. Handplockat för misstänkt övergivning. Inga ekosystemsiffror kan läsas av det.
• Ingen funktionstestning. Inte ett enda av de 35 verktygen kördes mot en live-sajt. Föråldring är en underhållssignal, inte ett funktionsomdöme.
• Nedladdningssiffror inkluderar maskiner. CI, speglar, ingen deduplicering och fönster som inte delar slutdatum. Installationsvolym, inte användare, och inte beslut.
• Sju okända orsaker förblir okända. Aktivitetsflödet gav inget svar, och för fem av de sju förklarar retention inte detta. Tom cell är bättre än ett populärt gissningsutfyllnad.
• staleness_days använder committer-datum. Omskriven eller bakdaterad historik skulle snedvrida det. Inget sådant upptäcktes, vilket inte är samma sak som att det inte finns.
• Ett referensdatum. 2026-07-27. Flera av dessa repos har sannolikt ändrats när du läser detta — särskilt newspaper, som committar regelbundet. Kör om de fyra kontrollerna; citera inte mina datum.

När en managed tjänst ändrar riskbilden

Varje kontroll här finns eftersom du med ett självhostat bibliotek äger föråldringen. Om en frusen HTTP-klient slutar bete sig som en aktuell webbläsare är det din incident, oavsett tid på dygnet.

Författarens not: Thunderbit är vår managed scraping-produkt. En managed tjänst flyttar en del underhållsansvar till en leverantör, men täckning, svarstid, inlåsning och leverantörens långsiktighet blir då en del av riskmodellen. Thunderbit utvärderades inte i den här repo-granskningen.

Den ärliga kompromissen: du avstår från möjligheten att läsa koden, låsa en version och fixa det själv klockan två på natten. För ett team som redan underhåller scrapers är öppen källkod ofta rätt väg — de fyra kontrollerna är hur du gör det till ett beslut i stället för ett antagande.

Testa Thunderbit för extraktion av webdata

Kortversionen

Jag byggde en lista för att bevisa att GitHub döljer övergivna projekt. Illusionen är verklig för 14 av 35 repos och spektakulär i ett fall: sjdirect/abot visar en push förra veckan mot en default-gren som stått still sedan 2021, en lucka på 1 802 dagar.

Men mekanismen är smalare än berättelsen. Nio repos klarar alla villkor som påståendet kräver, och bara två av dessa nio — splash och geziyor — har positiv bevisning för att bots stod för uppblåsningen; resten klarar kravet genom avsaknad av bevis. Två flaggade repos är människor som försöker och misslyckas med att återuppliva ett projekt. Ett, crawlab, har 12 250 stjärnor och flyttade helt enkelt utvecklingen till develop. För sju kom aktivitetsflödet tillbaka tomt och retention förklarar inte fem av dem, så orsaken är inte fastställd utan antagen. Och för 21 av 35 repos rapporterade GitHub föråldring korrekt.

Det värsta fallet i datasetet passerar alla kontroller på repo-nivå. codelucas/newspaper committades den 2026-07-21; newspaper3k, senast släppt 2018-09-28, gick ut 813 513 gånger den månaden. I hela urvalet står 16 paket med releases äldre än ett år för ungefär 2,28 miljoner installationer i månaden.

Kontrollera default-grenens commit-datum, registryns release-datum, archived-flaggan och npm-fältet för deprecation som första triage. Verifiera paket-till-repo-attribuering och utveckling på icke-default-gren innan du drar en slutsats.

Testa Thunderbit för extraktion av webdata Get Started Free

Vanliga frågor

Vad är pushed_at och varför betyder det inte ”senast uppdaterad”? pushed_at är GitHubs API-fält bakom sidans aktivitetstidsstämpel, och det uppdateras när något pushas till vilken gren som helst. Det senaste committet på default-grenen är en signal om repo-underhåll, medan pakethanterare normalt installerar registry-artefakter eller upplösta modulers versioner. I den här granskningen hade 14 av 35 repos mer än 180 dagar mellan de två GitHub-datumen.

Är det alltid dependabot som blåser upp tidsstämpeln? Nej, och det visade sig vara den svagaste delen av folkförklaringen. Räknat endast på händelser som inträffade efter det senaste committet på default-grenen är bots bekräftade i 3 av de 14 flaggade reporna (splash 4 av 4, geziyor 5 av 5, any23 16 av 16). För 2 är det direkt fel: dragnets lucka kommer av att en människa pushade en omergad port till Python 3.10. Två till är blandade, inklusive crawlab, där 24 mänskliga pushar gick till develop och test medan main stod still. Och för 7 gav aktivitetsflödet inget alls, så orsaken är inte fastställd — retention förklarar bara två av de sju.

Betyder ett föråldrat repo att verktyget är trasigt? Inte utifrån det här underlaget — inget här kördes mot en live-sajt. Föråldring spelar olika roll beroende på hur snabbt målet förändras: webbläsarautomation, HTTP-klienter som efterliknar webbläsare, platsspecifika parsers och API-/LLM-wrappers åldras snabbt, medan algoritmbibliotek som SetSimilaritySearch eller simhash kan vara år gamla och ändå helt okej. tls-client är det tydligaste fallet i urvalet, med 790 305 installationer i månaden från ett repo som varit kallt i 905 dagar.

Hur kan ett repo vara aktivt men paketet ändå vara dött? Det är codelucas/newspaper, och det är det mest betydelsefulla den här granskningen hittade. Dess default-gren committades den 2026-07-21, dagar före referenstidpunkten, men newspaper3k på PyPI släpptes senast 0.2.8 den 2018-09-28 — 2 858 dagar — och drar ändå 813 513 nedladdningar i månaden. Repo-kontrollerna passerar; artefakten du installerar är åtta år gammal. Kontrollera alltid registryns senaste publiceringsdatum separat från commitloggen.

Löser arkiverade repos detta? GitHub visar ju en banner. Inte tillförlitligt, och @modelcontextprotocol/server-puppeteer visar varför. Dess npm-fält repository är null, så det finns ingen länk från paketet till det arkiverade repot och ingen banner att hoppa över. Det npm faktiskt levererar är paketets deprecated-sträng — "Package no longer supported" — som skrivs ut vid installation, och 127 232 installationer i månaden fortsätter ändå igenom. browserbase/mcp-server-browserbase meddelade sin nedstängning korrekt i sitt sista commit; dess 20 389 installationer föregår mestadels det committet, så de säger inte så mycket åt något håll.

Hur kontrollerar jag mina egna beroenden snabbt? Börja med default-grenens commitdatum, registry-versionens/uppladdningens datum, npm-fältet för deprecation och repo-flaggan archived. Verifiera sedan paket-till-repo-attribuering, granska icke-default-grenar när aktivitet avviker, och använd beroendegrafer eller lockfiler innan du kallar exponeringen transitiv. Namnkollisioner som de orelaterade Java- och PyPI-projekten wayback gör den eskaleringen nödvändig.