var execSync = require('child_process').execSync;
var fs = require('fs');
// Node 0.10 check
if (!execSync) {
execSync = require('sync-exec');
}So if your node instance is older than 0.10, it will fallback to require sync-exec . Unlike execSync which is a builtin module, sync-exec is, or was an old module that you have to install explicitly. If your node instance does not have that installed, boom!
The real issue is that why would you use such old version of node these days? You should have use the latest one possible, either 8.9.4 (the long term support) or 9.7.1 (the shiny one)
I recently encountered this issue randomly – which turned out because some of the servers have very old versions of Nodejs. The easy – but tedious – way to fix it is to install the latest version of Nodejs on all of those machines. But we have almost ten of them, so it’s not an option. We went with the more “contained” approach – to include nodejs in our repository. So when we want, we can just update Nodejs in one place and be done with it.
That is still not the end of the story. Now we have a Node.exe in our repository, but yarn still wants to use the “system”, old version node.exe, and fail. We had to add the path to “our” node.exe, like this:
set PATH=C:\repo\tools;%PATH%;
It’s important to add your custom path before the system path. The reason is obvious – Windows tries to find in every path until it can find the node.exe it is looking for. Because we want it to use our `node.exe` – we need it to find in our repository first.
If you are using MSBuild, set a command like this
<SetEnvironmentVariable Variable="PATH" Target="Process" Value="$(MSBuildPath)\Tools;$(PATH);"/>
And you’re good to go
