For ease of use, I will use a build too to automate the various steps required to build my project on a new computer - like installing dependancies and so forth.

Once I've got that all automated, how can I test it? I don't have a 2nd machine to try it on. I don't want to mess up my currently-working environment by first uninstalling the deps and then using my script that might not work as expected.

Should I install a VM, docker? Is there any other approach?

1 Answer 1


Ideally your build process is completely isolated and does not muck around with the global config of your computer. The user should be able to select any paths instead of assuming that the project exists in a specific location. If the build process gathers any dependencies, these should be stored within the project directory.

If you've written such a sufficiently isolated build script, all you need to do is create a clean directory and run your build process there.

However, it is easy to overlook some dependency, so testing on the same computer does not give much confidence. You should do it anyway because it's a low-effort way to find basic problems with your build process. It's easier to debug these problems on your computer than in an unfamiliar environment.

For better results, yes you will need a second machine or a VM or some containerization technology. If you don't want to run any VMs on your computer, you still have a number of options. If this is for open-source development there are some free continuous integration services you could look into. If this is commercial development, you can surely afford to rent a virtual machine from a Cloud/Webhosting provider. For occasional testing, it is also sufficient to keep a cheap second-hand machine in your office that you remote into. E.g. I once set up a cheap Linux box with a Jenkins server that would run the complete build script every night at 2am – that way I didn't mind how slow that machine was.

  • +1, but when I first setup my machine, local installation for some node modules failed and I could only get them to install globally. Yes, I realize doing so via my build script would be a bad idea. But even if I create a sufficiently isolated build script, will I still be able to test it on my current env with redundant/conflicting global installs? I think I would need to teardown my current env in that case. Aug 9, 2017 at 18:45
  • 2
    @Pat I don't really have any experience with Node. For other platforms, I know how to check that modules are only searched locally, thus verifying that globally installed dependencies are ignored. After that, testing locally is fine. But this is also a hint that containerization like docker might be a good fit – you don't care if something is installed globally within the container as they are disposable.
    – amon
    Aug 9, 2017 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.