This package is no longer supported from Atmosphere, and will be installed from NPM from Meteor 1.3 and up.
Is this recommended way of packaging? I thins strongly Meteor related packages still should be published on atmosphere. At least until Meteor core will be on Npm as well and Atmosphere become deprecated (and we didn’t get such information yet).
I bet @Urigo would be best to answer here, but I think this is to be more consistent with the React installation experience, which will also come from NPM. The main benefit is that you can get new versions straight from the source, without waiting for a new Meteor integration.
But in React case it will be pure React (npm install react) packed by Facebook and in this case it’s Angular2-Meteor (npm install angular2-meteor) packed by one of MDG employees
I’m curious: What is the reason for thinking strongly about this? Because 1.3 isn’t out yet? (Meaning the core is still on Atmosphere)
Once we have 1.3 would you still like to find packages on Atmosphere? Could Atmosphere be a simple wrapper for Meteor packages on NPM? Just like http://react-components.com/ is for React.
Personally I rather do
npm i angular2-meteor
then
meteor add urigo:angular2-meteor
Simply because NPM is the standard for almost all Javascript packages (except for Meteor until 1.3 comes out).
With Meteor 1.3 we plan to ship angular2-meteor and angular-meteor data integration through Npm.
Then Npm.require that package inside the regular angular2 and angular Meteor packages.
That means that if you like the way you work now, everything will still work, but, if you prefer to work like all the rest of the Angular community you will be able to do:
npm install angular
npm install angular-meteor
meteor add angular-compilers // which will consist of `angular-html-templates` (now called angular-templates) and `pbastowski:angular-babel` (until we will get everything inside the official `ecmascript`)