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).
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.
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.
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.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.
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 atmospherejs.com in the long term is unclear, but it’s clear that we should wait on prioritizing until the picture has cleared up a bit.