Please help me understand something about how meteor handles atmosphere packages with built npm modules.
Background
I have a Meteor application which is currently using Meteor version 1.3.2.4.
I am using nvm to set my node version to 0.10.46.
I have a package localpackage which uses a package csats:libxmljs published on atmosphere. csats:libxmljs depends on the NPM module libxmljs which requires building via node-gyp.
When I try to run: spacejam test-packages --release 1.3.2.4 --driver-package=practicalmeteor:mocha-console-runner I get the following error:
W20160803-15:50:21.236(-7)? (STDERR) /home/csats/.meteor/packages/meteor-tool/.1.3.2_4.1misk9x++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:267
W20160803-15:50:21.236(-7)? (STDERR) throw(ex);
W20160803-15:50:21.236(-7)? (STDERR) ^
W20160803-15:50:21.238(-7)? (STDERR) Error: /home/csats/.meteor/packages/csats_libxmljs/.1.0.3.17zdh6u++os.linux.x86_64+web.browser+web.cordova/npm/node_modules/libxmljs/build/Release/xmljs.node: undefined symbol: node_module_register
W20160803-15:50:21.238(-7)? (STDERR) at Module.load (module.js:356:32)
...
I read that node_module_register is part of newer versions of Node. Thus, this error happens because the libxmljs npm module was built for a newer version of Node than my version of meteor is using.
I can make everything work by going into .meteor/packages/csats_libxmljs/1.0.3/npm/node_modules/libxmljs and running:
node-gyp configure
node-gyp rebuild
What I believe
This is because the package publisher built and published the package using the 1.4 version of Meteor tool which built the module for Node 4.
What I want to know
- Is my conclusion correct?
- If so, does meteor ever rebuild these npm modules for packages in the .meteor directory?
- Can package maintainers publish packages for both Meteor 1.3 and 1.4 given that they use incompatible versions of node?
- Should I solve this by pinning my package version to an earlier version which did work with Meteor 1.3?