nodeSetup: Couldn't follow symbolic link.

[rabbitfr]

Hi,

Sometimes the nodeSetup task is failing with the error
'Couldn't follow symbolic link.' on osx.

Cleaning the .gradle directory fixes the issue.

---

../gradlew build
:typescript-script-sample:nodeSetup FAILED

FAILURE: Build failed with an exception.

• What went wrong:
  Could not list contents of '/Users/rabbit/xxx/xxx/typescript-script-sample/.gradle/nodejs/node-v6.9.4-darwin-x64/bin/npm'. Couldn't follow symbolic link.

$> ll /Users/rabbit/xxx/xxx/typescript-script-sample/.gradle/nodejs/node-v6.9.4-darwin-x64/bin/npm
/Users/rabbit/xxx/xxx/typescript-script-sample/.gradle/nodejs/node-v6.9.4-darwin-x64/bin/npm -> /Users/rabbit/xxx/xxx/gradle-typescript-script-sample/.gradle/nodejs/node-v6.9.4-darwin-x64/lib/node_modules/npm/bin/npm-cli.js

[srs]

What version of the plugin are you using?

[rabbitfr]

 id "com.moowork.node" version "1.1.1"

[nkoterba]

@rabbitfr, @srs Same issue just emerged on my box.

    id "com.moowork.node" version "1.1.1"

I tried to remove my .gradle directories in my source tree, but still get the error:
FAILURE: Build failed with an exception.

Error on Mac OSX:
Could not list contents of '/Volumes/tempb/SNAPLab/SNAP/code/webclient/app/build/nodejs/node-v6.9.2-darwin-x64/bin/npm'. Couldn't follow symbolic link.

[nkoterba]

@srs I think I've discovered what our issue was regarding this:

We configure our gradle GulpTask with inputs and outputs so that the GulpTask is only run when source files are updated.

For task inputs, we include the entire Javascript src directory which also happens to have other nested Gradle subprojects that also use the MooWork Node and Gulp plugins.

Something (whether it's the Moowork plugins or Gradle) is installing a copy of npm in a .gradle directory in these nested subproject folders.

Thus, we had several .gradle folders in our src directory folder and when our top level GulpTask was trying to determine the inputs for the task, it would try to "walk" the symbolic links found in the npm/bin directory installed in the nested .gradle folders.

Here's our folder structure:

And here was our "failing to run" gulp task:

task gulpBuild(type: GulpTask) {
    description "Builds webclient output. Build will fail on any javascript bundling errors."
    args = ['build', '--exitOnError', '--config', 'production', '--version', pomVersion]

    inputs.files fileTree("app").matching {
        exclude "**/dist"
        exclude "**/node_modules"
        exclude "**/build"
    }

    outputs.dir "app/dist"
}

You can see that we were not excluding the .gradle folders from our "inputs" file list so when it traversed the .gradle folder file tree it tried to follow the symoblic link and died. I guess the Gradle team could try to fix this for FileTrees or we look into an option that ignores symlinks, but the easiest and most sane fix was to just exclude .gradle folders from our inputs filetree:

task gulpBuild(type: GulpTask) {
    description "Builds webclient output. Build will fail on any javascript bundling errors."
    args = ['build', '--exitOnError', '--config', 'production', '--version', pomVersion]

    inputs.files fileTree("app").matching {
        exclude "**/dist"
        exclude "**/node_modules"
        exclude "**/build"
        exclude "**/.gradle"  // <== FIXES the issue
    }

    outputs.dir "app/dist"
}

We can now run our GulpTasks again :-).

Thanks to @rabbitfr for the hint about the issue involving .gradle folder.

[h3adache]

I had the same issue after upgrading to gradle 3.5 and @rabbitfr 's suggestion to remove the .gradle also worked for me. Not sure this is something solvable by the plugin. Stacktrace showed only gradle internal classes.

[rkrisztian]

I have the same error message when using NPM version strings like file:../some-other-directory, regardless of using such in the package.json or with yarn add. But only then. I wonder if the other reported cases are the same.

Removing .gradle is not an option for a CI build we are planning.

In detail:

Could not list contents of '/home/user/projects/someProject/node_modules/@someScope/some-other-directory/.gradle/nodejs/node-v6.9.1-linux-x64/bin/npm'. Couldn't follow symbolic link.

$ ls -l /home/user/projects/someProject/node_modules/@someScope/some-other-directory/.gradle/nodejs/node-v6.9.1-linux-x64/bin/npm
lrwxrwxrwx 1 user group 152 May 18 17:14 /home/user/projects/someProject/node_modules/@someScope/some-other-directory/.gradle/nodejs/node-v6.9.1-linux-x64/bin/npm -> ../../../../../../../../../../../home/user/projects/some-other-directory/.gradle/nodejs/node-v6.9.1-linux-x64/lib/node_modules/npm/bin/npm-cli.js

=> So I'm wondering, even if the link points to an existing file, why would would the plugin have anything to do with the .gradle directory of a completely separate project?

[planser]

Upgrading to version 1.2.0 fixed this problem for me.

[Hubbitus]

That happened also if you said move project (or just keep cache and building on different CI) and path changed - then symbolic link became broken. And instead of just fix symlink build failed.
Removing .gradle directory fixes that, but build again going longer...

Please consider fixing symlynk if it seams broken for you plugin.

[eugenio1590]

Any progress of this? I get the same issue in version 1.2.0. I am deploying my project using Heroku.

The problem is that Heroku does not keep the /app/tmp/ cache folder after compilation where node and yarn are installed. How to download node.js and yarn in each build?

[weiklr]

the solution in this link: https://discuss.gradle.org/t/how-can-i-make-gradle-ignore-dangling-symlinks/7152/7
helped me resolve this problem

[vahidhedayati]

ended up removing rm -rf frontend/node_modules and running ./gradlew frontend:start to pickup build node_modules all over again seems to fix it for me.

Was getting some other symlink issue:

node_modules/svgo/node_modules/js-yaml/node_modules/.bin/esvalidate'. Couldn't follow symbolic link.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

[javagirl007]

I came across this same issue when using node version 12.0.0. Downgrading to node version 10.16.3 helped me to get beyond this issue. Looks like it is a bug with node version 12.0.0.