Find npm in wrong place #152
Comments
|
I confirm that by default the plugin uses the You will probably think that my question is stupid but I ask it anyway: is |
Sorry for late reply. I'm using node installed by nvm. |
|
Ok for node, but is |
|
Yeah. I'm sure it is same env. Maybe it caused by architecture. I can build project by Gradle with this plugin on Rosetta2, but not in M1 Native. Maybe this issue related with this |
|
Indeed I did not noticed you are running a Mac M1. But I don't see why the Can someone using a Mac M1 confirm that it the problem comes from the platform? The issue #154 is not exactly the same problem. You are not asking the plugin to download and install Node.js, and this is what was reported as broken on Mac M1. |
|
Sorry for late replay.
Yeah. I can run on x86 JVM OpenJDK 11 with rosetta2. |
|
Ok, so you mean that the issue happens only when running an arm64 JVM. If you run a x86 one using Rosetta 2, you don't encounter the issue, right? |
|
exactly. |
|
Ok, that's interesting. We use the Gradle exec API to execute Can you run this class using the x64 JVM and the arm one? import java.io.IOException;
import static java.nio.charset.StandardCharsets.UTF_8;
public class JavaNpmExec {
public static void main(String[] args) throws IOException {
String command = "npm -version";
Process child = Runtime.getRuntime().exec(command);
System.out.println(new String(child.getInputStream().readAllBytes(), UTF_8));
System.err.println(new String(child.getErrorStream().readAllBytes(), UTF_8));
}
}If you use Java 11+, you can simply create a It runs |
|
@bsautel I'm running into the same issue when having Using a |
|
Ok, thanks for your feedback @alexpartsch. Unfortunately this experiment did not enable us to spot the origin of the issue but that's quite a good news there is not a such big bug in the arm64 JVM! We still have to find where does the issue come from. Let's check something on the Gradle side. Gradle 7.0-rc1 was released a few days ago and adds full support of arm64 JVM. They don't talk about exec related issues in the release notes but could someone check whether the issue is still here when using an arm64 JVM with Gradle 7.0-rc1 please? |
|
Hi! Got the same issue on M1. Using Gradle v7.2 and gradle-node-plugin v3.2.1. |
|
@MKaciuba just to confirm, that's getting |
|
Faced this issue on Intel Mac. The funny thing that it stopped working without any external changes. The day before I've launched several builds successfully and today 'Cannot run program "npm"'. Everything works fine from terminal. |
|
Could workaround the problem by setting: Adding |
|
Are you using Assuming it's |
|
Download is set to false by default. I tried to run |
|
I am also experiencing this: Reproducible for the first build run via IntelliJ after system boot. Once this error occurs, it persists for builds outside of IntelliJ, too. Stopping all Gradle daemons with I can confirm that Gradle itself sees the correct When using this issue does not occur at all. Environmentdownload = false (using default) Node & NPM via nvm macOS 14.2 on M2 Java 21.0.2 Gradle 8.6 IntelliJ 2023.3.5 |
|
Correction: Every build started via IntelliJ UI will fail with this error, if this build creates a new Gradle Daemon instance. If there is a Daemon created by a build outside of IntelliJ, i.e. terminal, the build run from IntelliJ will work, too. However directly triggering npm from IntelliJ UI works and a terminal started inside IntelliJ sees npm, too. So I still think this is unrelated to IntelliJ shell environment loading. I am unsure whether the Gradle version is a factor. Still investigating. |
|
@tzcsx ARM mac? var process = new ProcessBuilder("sysctl", "sysctl.proc_translated").inheritIO().start().waitFor();I suspect you're hitting the issue at: #154 (comment) |
|
Yes, ARM mac M2 and download = false. I tried this: tasks.register<NpmTask>("doStuffWithNpm") {
args.add("do-stuff")
val process = ProcessBuilder("sysctl", "sysctl.proc_translated").start()
val output = BufferedReader(InputStreamReader(process.inputStream))
process.waitFor()
println("configure " + System.getProperty("os.arch") + " " + output.readLine());
doFirst {
val process = ProcessBuilder("sysctl", "sysctl.proc_translated").start()
val output = BufferedReader(InputStreamReader(process.inputStream))
process.waitFor()
println("doFirst " + System.getProperty("os.arch") + " " + output.readLine());
}
}This results in "aarch64 sysctl.proc_translated: 0" for all phases in both the running and failing scenarios. |
|
+1 to experiencing this (and also on an M1 Mac), though my Even stranger, if I pause the debugger at the point the exception is thrown and run: new String(new ProcessBuilder("npm", "--version").start().getInputStream().readAllBytes());...it spits back out the correct version, apparently able to find Also, for me this produces 0 in the failing case, and I'm not downloading any ProcessBuilder("sysctl", "sysctl.proc_translated").inheritIO().start().waitFor(); |
|
The last handoff point is in But the The Manually running a simplified case in the same execution context seems to produce the same issue. execRunner.execute(project, extension, ExecConfiguration("npm", listOf("--version")))However, this works: ProcessBuilder("npm", "--version").start().inputReader().readText() |
|
Well, that's interesting. I get this failure when I run IntelliJ by opening it as an app, but if I start IntelliJ from a shell then I have no issues. cd project-dir
idea .Not exactly a satisfying workaround, but might point to the root of the issue (in conjunction with it not being a Part of what's still bugging me is that this is only happening for |
|
Well, this is interesting... 
So, the issue doesn't seem to be finding It appears that setting It's not clear to me exactly why yet, but I've traced it all the way down to a native call ( private ProcessImpl(final byte[] prog,
final byte[] argBlock, final int argc,
final byte[] envBlock, final int envc,
final byte[] dir,
final int[] fds,
final boolean forceNullOutputStream,
final boolean redirectErrorStream)
throws IOException {
pid = forkAndExec(launchMechanism.ordinal() + 1,
helperpath,
prog,
argBlock, argc,
envBlock, envc, // <- nulling out envBlock right before call results in success
dir,
fds,
redirectErrorStream);
processHandle = ProcessHandleImpl.getInternal(pid);
try {
AccessController.doPrivileged((PrivilegedExceptionAction<Void>) () -> {
initStreams(fds, forceNullOutputStream);
return null;
});
} catch (PrivilegedActionException ex) {
throw (IOException) ex.getCause();
}
}As one might expect, setting the I've got a diff of the environments running IntelliJ normally (from GUI) and with the This is probably something to do with macOS permission weirdness. Who knows, it might just suddenly start working after an update... still, that a |
|
Well, that's out too. In the debugger, at the site of new String(new ProcessBuilder(processBuilder.command).directory(processBuilder.directory).start().getInputStream().readAllBytes())Produces: The only difference between this process builder and the one created by Gradle internals is the explicitly set
|
|
Well, in the end I think this issue is not at all related to tasks.register("mystery") {
val pb = ProcessBuilder("lua", "--version")
pb.environment().clear()
pb.environment().putAll(System.getenv())
val str = pb.start().inputStream.readAllBytes().decodeToString()
println(str)
}This also fails ( |
|
I am still running into this every day. The first build of the day needs to be started outside of Intellij in order to produce a working Gradle Daemon process which successive Intellij builds will then use. @DylanLukes You've dug deep there, thanks. So it looks like this is either a Gradle or Intellij issue, but nothing @deepy can look into. Could you escalate this in a Gradle ticket? The Gradle team should be able to decide if this is related to Gradle itself or if it is a problem with Intellij's MacOS init logic. |
|
Following the investigation I think this sounds like it could be related to gradle/gradle#10483 (comment) and https://youtrack.jetbrains.com/issue/IDEA-334183 Which to my understanding means that if you're on Java 21 i.e. PATH changes will look like they work, but won't In short this is a bit of a headache and means I need to run cross-version tests for Java as well |
|
@deepy Good find! I can confirm that either building with Java 17 instead of Java 21 or using Java 21 and starting Intellij from the Terminal via |
|
Had the same problem (running 21 in idea) and In general, is a fix being worked on? Is there even an in-principle solution to this problem that can be pursued? |
|
There's a mix of issues in this one |
Related the document, plugin have to find npm on global scope, but it is not.
So, I tried to override npm or node excitable path but no effect
My environment is like below.
The text was updated successfully, but these errors were encountered: