Question

I’ve been playing with Meteor (and Meteorite) for a bit and love the ease in which I got things up and running. Now I’d like to add some tests to the app and found that the main hurdle was including references/requires to packages used by Meteor in the test scripts.

As an example, I have a simple class that I wrote which internally uses some underscore methods. Then I wrote a simple mocha script to test it.

When I run

mocha my_test.js

it complains that _ is undefined. If I add

var _ = require('underscore')._

to my test code, it can’t find the underscore library because the packages are all wrapped up in a tight little bundle which is not on the NODE_PATH for mocha. I could specify that path, but that kind of hard-coded path seems like a bad idea.

Is there a way to run a node process/script (like mocha) in the Meteor environment? I’m looking for something similar to ‘bundle exec’ from ruby-land. I’ve looked into Meteorite and it seems to pretty much pass commands right down to Meteor so I was hoping you guys might want to field this one.

UPDATE:

After writing this, I started looking at the meteor source code. I was able to write up something that does mostly what I want and thought the Meteor team might comment on whether or not this seems like a good path to go down. Starting with the meteor shell script (/usr/local/meteor/bin/meteor), I added a case statement at the bottom that switches modes based on the command name. This file can replace the current meteor startup script and then you add a link from meteor-exec to meteor and voila. With this replacement script, I can run meteor in the normal fashion. I can also run

meteor-exec `which mocha` tests/mocha_test.coffee --compilers coffee:coffee-script

And I get the results I expect. I can require(‘underscore’) which is pulled from the third party libraries from Meteor. And I can include ‘mocha’ and ‘chai’ which are in my npm global package space.

If this appears to be of the right mindset, and the code agrees with the way you guys might proceed, I can submit a proper pull request.

The replacement meteor shell script is in this gist https://gist.github.com/4416913. I’ve added the diff below.

Thanks, in advance

Mr Rogers

ps. keep up the good work. I’m really loving Meteor.

diff meteor meteor.orig 
105,116c105,106
< NPM_GLOBAL_PATH=$(npm root -g)
< METEOR_THIRD_PARTY="$DEV_BUNDLE/app/lib/third"
< case $(basename $0) in
<   meteor)
<     export NODE_PATH="$DEV_BUNDLE/lib/node_modules"
<     exec "$DEV_BUNDLE/bin/node" "$METEOR" "$@"
<     ;;
<   meteor-exec)
<     export NODE_PATH="$DEV_BUNDLE/lib/node_modules:$METEOR_THIRD_PARTY:$DEV_BUNDLE/packages:$NPM_GLOBAL_PATH"
<     exec "$DEV_BUNDLE/bin/node" "$@"
<     ;;
< esac
---
> export NODE_PATH="$DEV_BUNDLE/lib/node_modules"
> exec "$DEV_BUNDLE/bin/node" "$METEOR" "$@"

Answer 1

You’re right that this gives you access to underscore and the node modules but as you said, you won’t be able to access meteor packages this way (ie you won’t be able to use Meteor.Collection). Also worth pointing out that admin/node.sh in our Git repository does the same thing as your meteor-exec.

If you want to try to build a more complete solution, take a look at app/server/server.js to see how we load packages. You’ll need to do something like this to be able to test code that relies on Meteor itself. An alternative would be to create a smart-package wrapping mocha. There is currently no easy way to depend on NPM modules directly from Meteor packages (this is in the works), but you can just copy over the mocha source into your package. Then you could get to a point where just running meteor within your app runs your mocha tests (albeit while still running a web server listening on port 3000, etc)