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 http://jssolutionsdev.com/ 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 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.
1 Like
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:
2 Likes
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.
2 Likes
How do you maintain/install packages that target both the browser and server with shared code? Does/will NPM support that?
1 Like
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 package.json file?
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.
2 Likes
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.