<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Towards Using Package Centrality Trend to Identify Packages in Decline · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2107.10168/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2107.10168/feed.xml" rel="self" type="application/rss+xml" /><item><title>Towards Using Package Centrality Trend to Identify Packages in Decline — mentioned by suhaibmujahid</title><link>https://news.ycombinator.com/item?id=28248419</link><guid isPermaLink="false">urn:hackerpapers:mention:2107.10168:28248419</guid><pubDate>Fri, 20 Aug 2021 17:01:59 GMT</pubDate><description>&lt;p&gt;The npm registry has more than 1.7 million JavaScript packages. While the community shifts to adapt to new packages (usually better ones). New packages are not necessarily better. But, if the community is moving toward using a specific modern package, probably it is for a reason. The question is: How to measure the community shift? Can downloads catch that? Actually, downloads are not quite good at that. We created a Chrome extension called &amp;quot;Centrality Checker&amp;quot; to help you not to be left behind. Our tool prototype uses the package centrality over time to identify community interest. More…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2107.10168/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.SE</category></item></channel></rss>
