Do you have EnvInject plugin installed?
If yes than you fall in JENKINS-26583

Workaround is remove EnvInject plugin, or make a custom build of workaround-26583 branch. (this branch will never merge into master, it's a EnvInject plugin issue not nodejs)

Those are some horrible workarounds nfalco. Since the EnvInject issue has existed since at least January 2015, something was obviously removed from the NodeJS plugin that was allowing npm commands to function prior to v1.0. I understand that the root problem is an EnvInject plugin issue, but you've just broken a bunch of users (including my company and all of our Node-dependent builds), in place, by removing the workaround. This is bad form. You don't force another project to fix their issues by breaking your product for a bunch of your own users. And my options are to uninstall another plugin and break 75% of our builds, or start rolling custom plugin builds? Really?

adamdille I'm sorry BUT I become the maintainer of this plugin only on late november and the refactoring of this plugin was done by ndeloof (that I know, one of major bee developer). The refactor consist in a major update of Jenkins API for BuildWrapper (steps that contribute the Enviroment) that corrects the wrong way of NodeJS to set the PATH variable similar to Envinject that cause the same issue to other BuildWrapper plugins (see JENKINS-24425 for example).

I strongly agree with the work of ndeloof. I aware of EnvInject issue but a release of NodeJS was expected since a lot of time (14th febrary 2014) to be compatible with Jenkins 2.x. NodeJS and EnvInject plugin are not related (nodejs has not dependences to EnvInject), so I could not stop the develop of this plugin due unresolved issue of other unrelated plugin (like no other plugins does).

I could ship NodeJS with the workaround for JENKINS-26583, BUT it's not a best practice that I have to release workaround for issues in other plugin, consider that people could also not have EnvInject installed, and proposed workaround in the branch it's little bit dirty so I do not really want handle its side effect.

I had propose to you some valid options:

• remove EnvInject (you can also push for resolution of JENKINS-26583 or propose a PR)
• remain to NodeJS 0.2.1
• build and install a custom branch in our repository (the same that I have to use in my company)

Consider that all this stuff of issue management (and develop of plugin) are done in my free time at the week end or after work.

nfalco, I built plugins from both the custom branch at commit d6c6db7 as well as 2b6255c (just in case some of the post-1.0.1 stuff introduced an issue). After installing them and re-running builds, both of them gave me the same npm: command not found error as the public plugin v1.0.1.

Both commit are valid, I suggest to use latest on that branch.
Could you post me the configuration of NodeJS tool, the job config.xml and the output of echo $PATH from a shell script build step please?