Since full transition to npm is in the roadmap I’m trying to stick to npm packages, yet my app still depends on a lot of atmosphere packages, so I wanted to understand how to proceed to proceed from here.
General questions/points:
How would you go about minimizing your dependencies from atmosphere systematically?
What aspects might prevent atmosphere plugins to be migrated to npm already? How could this be facilitated?
Maybe the guide could be extended with how to migrate an atmosphere plugin to a npm plugin, cases in which it is possible and cases in which it is yet not possible
What about working but unmaintained atmosphere plugins?
A full transition to npm is mentioned in the roadmap, and it will likely happen at some point, but the roadmap hasn’t been updated in a couple of months. Since its last update MDG’s priorities for Meteor have shifted a bit, putting the focus on Apollo integration with Meteor for release 1.5. Switching over to npm for as much as you can sounds great, but I wouldn’t worry much about prioritizing this work over other aspects of developing your application (yet anyways). That being said, here are a few answers to your questions.
First find out which packages you’re using that either have an equivalent package available via npm, or are just npm wrapper packages. Remove these packages and switch over to using the npm based equivalents. After that, things get trickier. If a package you’re using isn’t available via npm, or a similar npm package doesn’t exist, then you’ll either have to look into creating an npm based version of that package yourself, or ask someone else to (like the original package author(s)). This could be tricky however for Meteor packages that have dependencies on internal Meteor packages (see my next answer).
Packages that have dependencies on internal Meteor packages can’t be easily migrated to npm, since Meteor itself hasn’t been migrated to npm. Some internal Meteor packages have been migrated over by helpful community members (and some MDG staff members), but these aren’t officially supported packages. Using/relying on them could be risky. If you’re up for some “light” reading, check out the 143 comment Move Tracker and all other dependencies into separate repositories and NPM issue thread.
All contributions to the Guide are welcome - you can open an issue on the Guide’s repo to start a discussion about this, then submit any PR’s to help push the Guide ahead. That being said I think until (if) Meteor itself has been migrated over to npm, there are a lot of issues that can’t be addressed (so a section about this in the Guide would be fairly incomplete). Still, anything you can think to add now that will help would be great!
MDG has stated that they will personally take ownership of any working but unmaintained packages, and migrate them over to npm … at least I think I heard that somewhere … . Seriously though you’ll either have to migrate a copy of the package over to npm yourself, or try to convince someone else to take care of it.
Another thing to consider is that NPM packages don’t have support for client/server separation as far as I know (addFiles("foo.js", "client/server") and Meteor.isServer/isClient))
. Seriously though you’ll either have to migrate a copy of the package over to npm yourself, or try to convince someone else to take care of it.