A time before packages
Back in the “old days” when Meteor first appeared, despite listing “smart packages” as a core feature of the framework, there was actually no easy way to include a custom package in your app. The
packages/ directory didn’t exist, nor the
PACKAGE_DIRS environment variable. There was no documentation of the package API.
If you wanted to write your own package, as many intrepid developers did, the only way to include it in your app was to clone the Meteor repository, place your package there, and manually run your app using the checked out version.
It was a pain, it didn’t scale to more than one app, and it was hard to develop applications with others because it required you to have a version of Meteor modified in the same way. In short, it sucked.
The dawn of Meteorite
Nevertheless, people did start writing packages, and a few even made it to GitHub. However, it wasn’t getting any easier to use them. Until Mike Bannister came along.
A prominent member of the Meteor community, Mike took it on himself to improve the situation. His Herculean efforts and painstaking work with node filesystem libraries resulted in the first version of
mrt – a.k.a Meteorite. This tool automated the process of checking out a custom Meteor version and attaching a set of checked out packages to it.
Soon afterwards I joined in the efforts and we quickly improved the tool to deal with dependencies between packages, submodules (for “wrapper” packages) and many other conveniences.
Meteorite and the birth of Atmosphere
The tool was eminently usable, and packages started to appear on GitHub profiles everywhere. But there was no easy way to find them or add them to your project without manually twiddling with your
The obvious next step was to create a repository where people could discover packages. Thus Atmosphere was born. It consisted of two parts:
- A set of publications and methods that Meteorite could use to
- A website that developers could use to browse & discover packages.
The initial release of atmosphere was pretty simple, but it worked.
The website had humble beginnings. We had yet to exceed a hundred packages for the first few months so a flat list of all packages made sense. Search wasn’t really needed because the list was so short. It was a perfect tool for simpler times.
Merging plans, fallow times
Talks soon began of merging support for third-party packages and a repository into Meteor core. The Meteor team were keen to make it happen, but given the fact that the Meteorite approach “worked OK”, it fell down in the list of priorities.
Meanwhile Mike moved on to other things, and I was content to idle Atmosphere and Meteorite while awaiting the “upcoming merge”. In our stead, community contributors pushed on–especially Tarang Patel who added search and GitHub Readmes to the site.
Still, even as things stagnated a little, developers were happy. Creating and sharing of packages flourished with more than 1,000 added to the ecosystem.
Unfortunately, the site was never built for that many packages. Displaying all the packages on first render on the front page had some pretty serious performance implications for users and the Meteor servers. Arunoda Susiripala‘s Fast Render package was invaluable, but we still encountered server outages and load issues.
Moreover, there was another discovery problem that wasn’t addressed. Although you could search for packages, there was no way to order packages or discern which were active and worth using.
Something needed to be done. We (Percolate) decided to step up and build a new Atmosphere — a modern, fast, well engineered package manager to accompany the framework of the future. After much thought and work we crafted the Atmosphere 2.0 site to address the challenges of performance and discovery. Although it’s by no means a finished product, we think it’s a more effective way to discover the packages you need build your project.
Our overriding goal for Atmosphere is to make it easier to find good packages. We selected the features on our roadmap to help us achieve this goal. We hope our small contribution helps great packages find an audience, resulting in projects that change the world. Join us for the ride.
 Yes we are talking as far back as 2012.