Ideas for Atmosphere enhancement

I really like atmosphere !
I think atmosphere is one reason for the success of meteor.

Right now we have 7182 packages on atmosphere.
Would be great to if the search function could be updated. It is difficult to find the right package.

I suggest to enhance meteor / atmosphere with the following features:

  • Add tags to the package definition
  • Function to hide outdated or deprecated packages (at lot of packages are outdated or no longer maintained)
  • Function to show only packages which are compatible to the a specific meteor version
  • Add review, rating or comments directly to the package at atmosphere.
  • Function to hide packages without a github link.
  • Function to hide packages without documentation

Any other ideas ?


I agree with every single enhancement you suggested!

Hey @doedel. Thanks for your kudos and great suggestions. These are all features we’re considering adding. We will prioritize them in our next round of feature development and publish our roadmap somewhere public (most likely here on the forums).

It would be good if the packages could have some kind of grouping.

Like UI, Templating, Social, etc probably by filtering for those tags that you mention.

1 Like
  • Display the package version number
  • Display the package exports
  • Display if the package is written in javascript or coffeescript (maybe that’s a tag?)
  • Function to hide packages written in coffeescript
  • Badge or icon or something if it’s marked as isDebug
  • Similarly, it would be great if we could mark packages as containing a component
  • Homepages for namespaces, organization, and/or Release Tracks - for those folks running an org or creating a release track, it would be great to be able to add a short description, a link to a project page, etc.

Seems like folks would get a lot of mileage out of a tagging system if it were tied into the search functionality.


Or maybe even set a code standard on how to write packages (like - please go vanilla)?

I really dislike the way clicking on the search box brings up a new screen - either make it a text entry box ( and display the result) or make it a button which says “Search” but do not make the button look like a text entry field.


Great ideas to improve Atmosphere. Here are a few more:

  • display whether package works with blaze, angular, react

  • display whether package works with flow router

  • most recent date of github activity

Ability to filter searches on these criteria.

I completely agree – the current experience when you click to search is jarring and seems juvenile.

Hope this doesn’t get anyone down; but I’m pretty sure Atmosphere is on its way out with Blaze in favor of NPM. EMBRACE THE FUTURE


There’s a thing - npm plugins are made for npm. Not meteor.

Any word on how NPM packages will work with the client/server shared API methodology that Meteor’s current package system solves? Would a package just have to export two different modules for each? Would the client then have the server code and vice versa? I haven’t heard much about this.

1 Like

No idea, but NPM + module support is on the way with Meteor 1.3

1.3 will wipe out meteor containers for npm modules.
So we won’t have to wrap npm modules like css frameworks or code-refactors.
Just like there’re Semantic UI, React, Bootstrap packages that are no different to npm.

But some have nothing to do with packages implemented for Meteor, using Meteor methods, meteor techniques, involving meteor capacities, meteor problems, and of course meteor magic, we all came here for.

1 Like

I think that Atmosphere will play significant role in meteor ecosystem, when developers will try to build native packages for Meteor.

Is there any way to join community for improving Atmosphere ? Is there any kind of API ?

Atmosphere originated as a closed source development from Percolate before Percolate was acquired by MDG. Maybe @tmeasday could weigh in here?

At we would like to continue improving AtmosphereJS.
Looking forward to hearing thoughts from @tmeasday

I doubt we’ll be getting access to Atmosphere. But there’s Stratosphere, Fastosphere, and the MeteorPackages package that are all available.

I think @msavin is right to emphasize NPM as the “future” – At this point we’d rather see a situation where “native meteor” (whatever that means precisely) packages were built on NPM (which may mean NPM needs some features that Atmosphere packages currently use) rather than us using a different system from more or less the rest of the JS ecosystem.

What this means for in the long term is unclear, but it’s clear that we should wait on prioritizing until the picture has cleared up a bit.

1 Like