Hello Everybody,
I’ve been migrating a package (just to test) to npm and i’ve found out a lot of issues:
What do you think about this?
Actually I also had similar question. What are main cons and pros about migrating to NPM? Do you have them? I heard about some pros like “Everyone is moving into NPM, we don’t want to support our own packaging system etc.”, but is NPM better than Atmosphere in all cases?
Probably not better if you from a technical point of view.
But it’s not always the technical best solution that wins. NPM has proven to be the winner, even with all its shortcomings.
Meteor choosing for NPM opens it up to a larger audience and this may in the long term be more beneficial than the things we’ll lose.
They wouldn’t need to if everything is on NPM…
And you can still depend on Atmosphere packages that are not ported to NPM.
Even Atmosphere would eventually need to go this route, if Meteor wants to keep up with new node versions.
Btw, it’s not manual compilation (what does manual compilation even mean: you writing the assembly code?), it’s still automatic, it just happens on your computer. Meteor just needs to make sure the compilation goes smooth, which IMO is very often not the case with node-gyp.
Well, it’s up to Meteor to make npm install package and meteor install package the same seamless experience.
can MDG figure out a way for package developers to add a flag to their npm package’s package.json?
Then all future packages can be built on npm but the flag would trigger any meteor specific needs… builds, etc?
We’ve had this discussion about 19 times now. 
I feel you bro, we lost a little something along the way - but ultimately it’s about attracting more Javascript developers into Meteor.
I meant that right now you need to use Babel or whatever in orden to transpile an npm package, adding ecmascript is not working anymore.
For me thats a step back.
To sum up, i feel that the npm integration is still in beta, it was released just to make the community happy but is still not a nice option, at least speaking about writing packages.
This is just my personal opinion.
I don’t want to convince anybody, just to discuss and see different points of views.
tbh that’s one of my biggest concerns summed up in your final sentence:
Well, it’s up to Meteor to make npm install package and meteor install package the same seamless experience.
A few things (such as the direction & discussion we had at 1.3 release about the Tutorials pages) seem like they actually aren’t going to go the route of making the experience seamless or emulate current Meteor implementations.
I really hope Meteor sticks to the core beliefs/direction that it was created upon. I’m all for growing - I just hope the “Meteor Way” does not get left in the dust for the “JavaScript way”.
Meteor made working with JavaScript even more pleasurable to work with, when Meteor was controlling the direction. I just hope that instead of this, JavaScript does not determine the direction of Meteor and the Meteor Way gets forgotten.
I’m not here because JavaScript alone. I was developing in js before I discovered Meteor. I’m here because of the Meteors way of doing things - not JS’s! Javascript has other options, I chose Meteor for a reason. I hope that reason is still around once all the new features are completed!
As someone who uses Meteor at my work place daily, and has had to teach employees how to use it (without any decent tutorials as employees started post-1.3, and the tutorials did nothing but confuse them!), I hope after Apollo, we get some nice QOL upgrades that makes all the new features (NPM support/modules/apollo integration) more pleasurable to work with. Bring them up to the “Meteor” standards we had pre-1.3!
I’d say it’s just as much about making the wider universe of JavaScript tools available to Meteor developers, and vice versa. For example, now you don’t need to wait for anyone to wrap the newest version of React for you, you can install it just like anyone else!
There are definitely some things we are working on in this direction. Ideally we can make something that improves package management for the whole npm/JS ecosystem!
In the interim, I have a package that watches local node_modules and on changes, compiles with babel and hotloads. Release is a little delayed while I get meteor-hmr working with Meteor 1.3.3, but it should be out by next weekend or not much later. Experience is as you’d expect; save a file, and within 1s the new transpiled code is hotloaded into the browser without a reload (as with meteor-hmr, it’s all client-side only for now).
Further info https://github.com/gadicc/meteor-hmr/blob/master/docs/Node_Modules_Hot.md, the beta works with Meteor 1.3.2.4 but no support until the stable release 
@benjamn’s comments in this pull request might help put people at ease a bit. Quoting the relevant bits:
Meteor 1.5 will be the first version of Meteor that is installable from npm, meaning that you can choose which version of Node you use, and you can use the Meteor build tool as a dev dependency of any npm package. That doesn’t mean there won’t be an easy way to install Meteor with all the prerequisites you might want; it just means you will have the option of providing your own versions of Node, npm, and possibly Mongo, if you need that flexibility.