Can not start node.js process (node), make sure your system has node.js installed.

[epsitec]

After getting back from vacations, I wanted to work on my projects, but somehow some recent software update broke my environment (I had several Windows Updates, Visual Studio 2015 Update 2 installed, updated Atom plugins, etc.).

First symptom

I always get the message Can not start node.js process (node), make sure your system has node.js installed.

However, I've got node.js configured in my PATH environment variable:

Path=C:\Windows\System32;C:\Windows;C:\Program Files\nodejs;...

and where node.exe returns the expected C:\Program Files\nodejs\node.exe.

Adding this to init.coffee for Atom gets rid of the message Can not start node.js process (node), make sure your system has node.js installed, but obviously, it should not be required:

process.env.WALLABY_NODE = 'C:\\Program Files\\nodejs\\node.exe'

Second symptom

Having Wallaby.js not complaining when I click on Start in the Wallaby.js panel does not help a lot, as I get stuck with the spinning wheel in the bottom right corner of the Atom editor, and nothing more happens.

Using atom 1.6 on Windows 7 x64.

All my previously working projects seem dead (e.g. /~https://github.com/epsitec-sa/electrum-store/)

[epsitec]

And by the way, I just checked in Visual Studio Code. Wallaby.js is running fine (same machine as the one where Atom does not play nicely with Wallaby.js).

[ArtemGovorov]

It looks like Atom somehow can't resolve your system node.js. We use the exact same code to start wallaby from VS Code and Atom, so it looks like an issue in Atom (which I can't yet reproduce locally). Anyway, setting process.env.WALLABY_NODE should help.

get stuck with the spinning wheel in the bottom right corner of the Atom editor,

In cases like this, we recommend to have a look into wallaby console, it may shed some light. Is there anything interesting in it?

[epsitec]

I am seeing lots of errors trying to spawn node:

[epsitec]

I'll try to reinstall atom and see if it helps.

[epsitec]

It did not help. I still see the same errors. Using Atom 1.7.0.

@ArtemGovorov contact me privately if you would like to have a look at my running system.

[ArtemGovorov]

It looks like it still can't find your node (or your init script is not used/wrong file/path is used). Try this:

• copy your node.exe from C:\Program Files\nodejs\ to just C:\,
• in the init script add process.env.WALLABY_NODE = 'C:\\node.exe',
• restart Atom, start wallaby.

[epsitec]

Does not work either. If I don't put node.exe at the specified location, I get the red pop-up with the error message, telling me that Wallaby.js cannot find node. If node.exe exists at the specified location, I get the error when trying Wallaby.js tries to spawn node.

/*globals __dirname */
'use strict';
var babel = require ('babel-core');
var fs = require ('fs');
var path = require ('path');

var babelConfig = JSON.parse (fs.readFileSync (path.join (__dirname, '.babelrc')));
babelConfig.babel = babel;

module.exports = function (wallaby) {
  return {
    files: [
      {pattern: 'test/test-helper.js'},
      {pattern: 'src/**/*.js'}
    ],
    tests: [
      {pattern: 'src.test/**/*.js'},
    ],
    compilers: {
      '**/*.js*': wallaby.compilers.babel (babelConfig)
    },
    debug: true,
    env: {
      type: 'node',
      runner: 'node'
    },
    bootstrap: function (wallaby) {
      // See http://wallabyjs.com/docs/config/bootstrap.html
      var path = require ('path');
      var sep = path.sep;

      console.log ('Setup wallaby');

      // Ensure that we can require self (just like what module 'require-self'
      // does), but remapping by default the path to './src' rather than './lib'
      // as specified by package "main".
      // See /~https://github.com/wallabyjs/public/issues/453
      var packageConfig = require (path.join (wallaby.localProjectDir, 'package.json'));
      var packageName = packageConfig.name;
      var modulePrototype = require ('module').Module.prototype;
      if (!modulePrototype._originalRequire) {
        modulePrototype._originalRequire = modulePrototype.require;
        modulePrototype.require = function (filePath) {
          if (filePath === packageName) {
            return modulePrototype._originalRequire.call (this, path.join (wallaby.projectCacheDir, 'src'));
          } else {
            return modulePrototype._originalRequire.call (this, filePath);
          }
        };
      }

      // Remove react from the require.cache, or else some code might not get
      // executed when editing the source code.
      // See /~https://github.com/wallabyjs/public/issues/321
      Object.keys (require.cache)
        .forEach (function (k) {
          if (k.indexOf (sep + 'react' + sep) > -1) {
            delete require.cache[k];
          }
        });

      // Include the test helper, which sets up the document and window objects
      // as globals:
      require ('./test/test-helper');
    },
    teardown: function () {
      console.log ('Teardown wallaby');
    }
  };
};

[ArtemGovorov]

Got it. This:

...
module.exports = function (wallaby) {
  return {
    ...
    env: {
          type: 'node',
          runner: 'node'
        },
    ...

is causing the ENOENT issue. runner: 'node' makes wallaby to try and run node command to spawn the default node (and it seems to be the issue when doing from Atom process chain). Try this:

...
module.exports = function (wallaby) {
  return {
    ...
    env: {
          type: 'node',
        },
    ...

or, if it doesn't work,

...
module.exports = function (wallaby) {
  return {
    ...
    env: {
          type: 'node',
          runner: 'C:\\Program Files\\nodejs\\node.exe'
        },
    ...

[epsitec]

Thank you, removing the runner specification completely or using the path to node.exe both solved the issue.

However, I still need to keep:

process.env.WALLABY_NODE = 'C:\\Program Files\\nodejs\\node.exe'

inside of the init.coffee file to get it to work.

[ArtemGovorov]

Ok, at least it now works.
Let's try something, add this

require('child_process').fork('', [], {execPath: 'node1'})

to your init script, restart Atom. You should see 'node1' could not be spawned. error in Atom. Now try changing it to

require('child_process').fork('', [], {execPath: 'node'})

and restart Atom. Do you see a similar error?

[ArtemGovorov]

Could you please also paste the output from process.env.PATH executed in Atom Dev Tools console?

[ArtemGovorov]

After googling the issue a bit, it seems that in some cases Atom doesn't have a correct PATH value passed/set.
It is the case if in Atom Dev Tools running process.env.PATH gives you values with no C:\Program Files\nodejs; in it.
If it's the case, try adding

process.env.PATH+=';C:\\Program Files\\nodejs'

to your init script instead of process.env.WALLABY_NODE = ... to see if it also fixes the issue. I have been also reading that launching Atom from the command line set the correct PATH, so you may try it as well.

[epsitec]

Here are my findings:

require('child_process').fork('', [], {execPath: 'node1'})

does indeed produce an error message, whereas the same with 'node' does not.

process.env.PATH is not set, however process.env.Path is:

That said, I added this line to the init.coffee file:

process.env.PATH = process.env.Path

instead of setting process.env.WALLABY_NODE and this works too.

[ArtemGovorov]

process.env.PATH is not set, however process.env.Path is

Great find! I have only been trying to pass the process.env.PATH and not the process.env.Path when creating wallaby node process. VS Code must be starting somehow differently as they have process.env.PATH set correctly. It also seems to be Windows specific and only to some version of it (I tried on 64 bit Win8 and Win10).

Anyway, thanks a lot for your help, the issue is fixed in the core v1.0.215. Note that after the core update (even if you force it), you'll need to restart Atom. Once updated you may remove the process.env.PATH = process.env.Path line from your init script (and restore runner: node in your config if you like, but I'd recommend to omit it).

[epsitec]

The issue has been completely solved with core v1.0.215. Thanks a lot.

Note: I've observed that on my laptop, everything has always been working fine, even if there too, process.env.Path is the only defined path environement variable inside of Atom.

[ArtemGovorov]

Great, thanks again for your help!