Please help me understand something about how meteor handles atmosphere packages with built npm modules.
I have a Meteor application which is currently using Meteor version 188.8.131.52.
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
When I try to run:
spacejam test-packages --release 184.108.40.206 --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/.220.127.116.11zdh6u++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?