Prune dependencies when running integration tests

[mennopruijssers]

Recently we used a dev-dependency in production code by accident. By pruning the dependencies to only use production dependencies during integration tests we make sure this doesn't happen again. However, while implementing it I discovered a problem with main.js: it requires commander and tchannel which are both listed as dev-dependencies.

[mennopruijssers]

(travis will fail until #268 is merged into master)

[thanodnl]

LGTM

[dansimau]

Not sure I agree 100% with the approach here but we're on the right track. My 2c:

• Pruning devDependencies during integration tests seems to make sense to me. 👍 It's an added check we can do to prevent relying on a dev dependency in production and would prevent the issue we had the other day.
• If main.js ("testpop") is part of ringpop-node, then I think we should include it's dependencies in the dependencies section of package.json (and not devDependencies, where it curently is); because it's a ringpop-node binary and it genuinely depends on those packages.
• However, because we're a library, we should be smart about this: to avoid our customers from having to install tchannel and commander then we should move our "testpop" binary to a subdir with it's own package.json. This is what ringpop-go does with its testpop..
• If we do that, the integration test runner just needs a build step for testpop. This matches ringpop-go.

I do not agree with adding a new whitelist to the integration test runner script itself. This seems like an obscure place to list yet another set of dependencies and I can see someone getting tripped up by this in the future.

[mennopruijssers]

Closing since we need a better way of doing this.