To confirm @tmeasday and @msavin comments, @debergalis says in his overview of Meteor 1.3 and beyond that you should use npm by default (and not Atmosphere, unless the package only exists there) after the release of Meteor 1.3:
From what we know from the announcements, the following should be coming:
- New data layer, Apollo, which opens the door for virtually any front-end and database to integrate with Meteor.
- Meteor core packages will be decoupled and published as NPM modules
- New build tool, based on Webpack
I would assume that the new build tool will run all of Meteor through NPM, and have select databases and front-ends that would have first class support. If that’s correct, I think the launch of that would be the end of Atmosphere.
I’m excited for the power of the new parts, but I hope the original Meteor stack would be maintained. Minimongo and Blaze is insanely fast and easy.
How do you maintain/install packages that target both the browser and server with shared code? Does/will NPM support that?
All great news from MDG.
Obviously, the feature that would most help migrate users off Atmosphere would simply be a ‘Migrate to NPM’ button.
Maybe it could fetch the git repository and returns a tarball with modified package structure?
Maybe it could generate a new
package.json file that users cut/paste into their package?
Maybe it could have a form to collect extra data for that
Beyond that, I wonder if there’s a role for Atmosphere/Stratosphere for Track/Release management; managing bulk uploads; and as a QA insights server.
nature to cool the planet, some researchers say that if the concentrations of carbon in the atmosphere reach a critical stage, geoengineering might become the only way to take control of our climate.
This is one of the things that I meant by “which may mean NPM needs some features that Atmosphere packages currently use”. We won’t support anything yet as of 1.3 but expect to see movement on this very soon after I’d say.
Ah… I see.
This is the thing* about atmosphere and the meteor package system that makes some of the best Meteor magic possible. Think:
meteor add accounts-password accounts-ui … to me, that’s just inconceivably good. It would be sad to see that goodness disappear or be diluted. Such a low maintenance burden for package authors too.
If that’s the way npm is heading, though, that’s good for Meteor and everyone who develops in js.
* targeting client and server with a single package that contains code specific to either environment or shared by both
Exactly, and this is the best outcome. I think we’ll get there on this specific question about the way Atmosphere packages work pretty easily.
Hopefully we can also get most or all of the other benefits of the existing package system too. Expect to hear more about this soon after 1.3 I’d say.
Maybe adding tags would be cool.
Or perhaps open sourcing it, for opportunity to just implement enhancements.
We need a way to curate Meteor packages hosted on NPM