Most packages do not work


Very simply said. Many of the packages I install have no function whatsoever. And many gives an red box telling me some error messages, and that it did a report automaticly somewhere.

I just tried more than ten new packages. They don’t do anything.
Only packages that seems to work somehow is the ones I use from the menu. For eg “Atom beatufy”. But the preview package do not. Or well it opens a blank box. From the menu but not ctrl+p. That opens something else.

So now I am thinking of a fresh install. But then all the themes etc. will vanish I suppose. Is there some other way?


Never mind. i did a fresh install and started to work…
However, maybe I get similar problems in the future. Fresh install cannot always be the best option.


When packages get screwed up you can delete or rename ~/.atom and restart atom instead of doing an install.


But I kind of agree with the problem.

Maybe plugins should get ranked down if they don’t get updates regularily. Atom is a living system which means that plugins that did have a higher chance to stop working if they are old and have not been fixed for new releases.

Or maybe a button similar to the star to flag plugins that seem to have more problems than what they solve?


Many of my packages aren’t updated regularly because they’re pretty simple and just don’t break. Should they get ranked down too?


What then is actually breaking? I get more than often a red error box. The editor might shut down by itself too.


I don’t think anyone can satisfactorily answer that without more information. What did the red error boxes say? What packages do you have installed? Have you followed the suggestions in the Debugging document? Which version of Atom are you using? What OS and version are you running?


Many of my packages aren’t updated regularly because they’re pretty simple and just don’t break. Should they get ranked down too?

Actually yes - I would start to rank them down - at least until someone presses a button and actively confirms that the repository version still works with the latest release of Atom or gives the plugin a version bump or something like that. WordPress has introduced a similar policy on their plugin repository some time ago.

That may be a (small) annoyance for package authors, but at least in my opinion there is nothing worse than a repository of outdated and broken addons that may even crash the software just because they have been built for an older version.

It’s not quantity that counts, it’s quality.


No one could possibly do this. It would require testing on all platforms and with all combination of packages. In other words this isn’t a binary situation.

That is a commercial operation with money involved, lots of money. That has very little in common with the Atom package situation.

Unless someone put in a ton of work there is nothing that can be done. Sorry.


Sorry, but I don’t agree. It’s not about doing a “everything is working with everything” test. There is no way of guaranteeing that - obviously.

However there are packages that just don’t work with newer versions of Atom, i.e. the main application. If the author may have lost interest in that package and does not maintain it, it will just remain in the package repository forever. Maybe it still works when the author moves on - months later Atom will introduce a breaking feature - and the package will stay there in it’s broken state, no one will be able to use it (unless he installs an ancient version of Atom) and it will just clutter up the whole experience.

I don’t think it’s too much to ask from Plugin Authors to release a version bump maybe very 6 months just to confirm that he’s still there and is still checking if there is any use for his package.

Not sure if you ever really worked with WordPress? The situation here is extremely similar - random users provide (usually free and open source - only some charge money) plugins to install into WordPress (the element in this equation with money). WordPress evolves, plugin authors loose interest, things break due to incompatibilities.

And even if there was a lot of money involved in their “plugin business”: A time based expiration mechanism is not really a feature that needs lots of money to have.


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.


Holy cow! Tell me you didn’t test every package. I hope this was just random sampling.


I actually didn’t really test any package.

You can use’s rest api to get a list of all packages.
I then downloaded each package.json (or tried, it failed 57 times) and analyzed the engines field of each package.

Obviously you can collect almost any metric you want, i.e. I used this method one or two months ago to create a diagram of all packages and the services they provide/consume.

It doesn’t take very long (it’s just 5k packages), but I threw in a delay between each download/api call for good measure.