TLDR; Meteor is still fun, NPM wrapped packages are bad. Instead of meteor add obsolete:wrap-everything you can use mainstream NPM packages with Meteor, today. Think about it! Look at meteor-webpack-react.

Is Meteor package system perceived as a lock-in by the NodeJS community and slowing down its adoption as data synchronization layer? Probably yes.

EDIT: Changed the title, added a real world example and a video.

An intro video of Meteor + Webpack by Adam Brodzinski

Meteor is cool, isn't it? meteor add whatever and you get a login system, Facebook / Twitter oauth, .. everything work but then the frustration comes.

I want latest Bootstrap. Should I use wtf:bootstrap or obsolete:boostrap ? Ooh Meteor integrates Blaze, Angular, React,.. should I use wft:react-grid-component or obsolete:react-grid-component ?

Version 0.0.12? WTF? I just want the latest mainstream release! You stop interacting with nodejs community, because you have Meteor wrapped packages, but you also get big headaches.

When Meteor started its package manager was useful, but now, after Babel ES2015 (and beyond), Webpack, React hot loader and NPM 3 browser friendly, it seems obvious that a package manager used mostly to wrap npm packages isn't useful.

Meteor 1.2 will have ecmascript ..

Yes, but it is wrapped :( And it still won't support ES2015 import/export until, maybe, Meteor 1.3 . If you don't want to depend on obsolete packages, freezed by others, there is an alternative approch.

Say goodbye to:

global variables to share functions or code among your files

obsolete mainstream packages

packages that require code on client and on the server even if you just need it on one side

Issues with loading code order

How a de-meteorized Meteor world look like?

Clone meteor-webpack-react and start to play with some packages like the other guys or girls.

$ npm install rrule --save

It will download and save it in the package.json and require it on the server or on the client, where you need it.

import RRule from "rrule"; let rule = new RRule(...);

The .js , .jsx files aren't automatically loaded. The files app/main_client.js , app/main_server.js are the start points for the respective environments. That's it.

You can still use the Meteor specific packages, a la Meteor way, look inside meteor_core but you don't have to, and they'll expose the global variables as you are used to.

You can also install private local packages with npm link and take advantage of other "normal" features for NPM users. The isolated meteor community could publish in future Meteor-specific packages on NPM, just adding the tag meteor or meteor-packages , the same of what is happening in the React community with react-components which is only a tag over NPM.

Real World example: an app I'm developing

It's a Meteor/React app and I'm using as deps:

babel , the original, instead of Meteor packages ecmascript or grigio:babel . Advantage: I can have latest Babel ES2015 compiler just changing a number in package.json

, the original, instead of Meteor packages or . Advantage: I can have latest Babel ES2015 compiler just changing a number in universe:modules for ES2015 import/export, opss no.. I already have it out-of-the-box.

for ES2015 import/export, opss no.. I already have it out-of-the-box. material-ui instead of wrapped izzilab/material-ui

instead of wrapped rrule instead of the outdated aramk:rrule , and I can also choose to load it where I need it at application level (client, server or both).

instead of the outdated , and I can also choose to load it where I need it at application level (client, server or both). react-headroom instead of ..nothing because there isn't a working wrapped version for Meteor

instead of ..nothing because there isn't a working wrapped version for Meteor I use React Hot Loader for client-side changes which is much faster than Meteor reloads.

Conclusion

Angry, shocked, sad? Here some comments on Crater.io and get a pill.