I don’t disagree with the idea of having some form of quality control, but simply asking everyone after some time interval to verify their own packages only creates a (minor) annoyance for the 80% of this community that know how to properly maintain their projects, just to “punish” the 20% with broken stuff.
A lot of problems of the current package market (if you can call it that) stem from big API changes (the biggest being Atom 1.0).
I ran some tests (I assume my internet connection is fine):
There are ~57 packages that cannot be installed because their GitHub repo has been deleted.
~6 packages fail because their version requirements (
package.json>engines>atom) are not met by recent versions of Atom.
These packages definitely don’t work (in 1.0+) and could be removed.
There are probably a lot more than 6 packages failing because of version requirements, but ~168 packages either set their engine version to
* or don’t have one at all. These packages imply that they work on all versions of Atom, even though they probably don’t. Same thing with packages that haven’t received an update post-1.0 (I don’t have any stats on that though).
Anyway, this leaves us with ~4800 packages to check manually … but do we really have to ?
Functionality is one thing, but do all 4800 packages do something truly unique ? - No, they don’t.
Many features are implemented by dozens of packages with varying success and more often than not, there are one or two packages that work the best and they are usually the packages with the highest download counts for said feature.
You can’t always trust download numbers (for reasons outlined in this thread) but it appears that, for now, the package ecosystem works just fine. There may be cases where package(s) fail to deliver, but most features of modern text editors / IDEs have at least one package that works exactly as expected and they always appear as #1 in the search results.
There are 3329 (+/- 80) packages with less than 1000 downloads. Some of them may have low download counts because they cater to a niche audience, but many of them are simply re-implementations of more popular packages and as long as their popular counterpart isn’t broken beyond recovery, we can just leave them be.
WordPress has 43500 plugins, they need quality control. Atom is a relatively young project with a little less than 5000 packages. We don’t need an expiration mechanism right now.
We could clean up atom’s package registry by removing a few packages from the pre1.0 era, but it’s not necessary.