Congrats to mdg for meteor 1.3, modules and npm integration are awesome.
Is there any difference if I’m using the local npm
installation or meteor npm
?
Congrats to mdg for meteor 1.3, modules and npm integration are awesome.
Is there any difference if I’m using the local npm
installation or meteor npm
?
meteor npm
calls the bundled npm version, so it doesn’t require npm to be installed globally. That is just a convenience however, so if you do have npm installed using that will work perfectly fine.
Are they exactly the same? I could not use bcrypt
from within meteor if I installed it with npm install bcrypt --save
(it was however working fine from a node CLI) It failed with:
=> Exited from signal: SIGTRAP
(STDERR) dyld: lazy symbol binding failed: Symbol not found: _node_module_register
(STDERR) Referenced from: /Users/me/app/node_modules/bcrypt/build/Release/bcrypt_lib.node
(STDERR) Expected in: flat namespace
This SO response suggested that meteor npm install
would fix the issue, which also worked for me
If your globally installed npm
version exactly (or at least closely) matches your meteor npm
version, then you should be okay. That being said I think its a good practice to get into always using meteor npm
, as that way you can make sure you’re using the same npm version that has been tested with your current version of Meteor.
A lot of reported npm
versus meteor npm
issues come from differences between how npm@2 and npm@3 work. You can see a good example of this in issue 6799; I’ll quote @benjamn’s great explanation of this below:
That’s very likely because npm@3 hoists conflict-free packages to the top-level node_modules directory as much as possible, which gives a flatter structure to your npm packages, but can also make packages like babel-runtime accidentally available to packages that didn’t explicitly depend on them.