yarn 1.12.1 creates .bin folders inside dependency folders

[justinmeiners]

1.12.1

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
Installing a dependency with a binary not only adds a .bin to node_modules, but also to the dependencies own folder.

This did not happen in yarn 1.10.1.

If the current behavior is a bug, please provide the steps to reproduce.

1. Install yarn and node in a docker or lxc container
2. Create a module with a dependency that includes a binary (that is installed to node_modules/.bin). Suppose for example marked
3. run yarn
4. look in node_modules/marked/ there will be a .bin folder.

What is the expected behavior?

Dependencies should not have .bin folders with extra symlinks.

Please mention your node.js, yarn and operating system version.
node: 8.12.0 (also tried 8.11.3)
yarn: 1.12.1
OS: Ubuntu 18

I tried the error on multiple ubuntu and debian container images.

EDIT: I thought this was only occurring inside containers, but it turns out only the containers were updated. I suspect this just broke in the newest 1.12

[kaiyoma]

I think I just ran into this as well. After upgrading to 1.12.1 (from 1.10.1) and running yarn install, I started getting a new error:

yarn install v1.12.1
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.4: The platform "win32" is incompatible with this module.
info "fsevents@1.2.4" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
error An unexpected error occurred: "ELOOP: too many symbolic links encountered, stat '...\\node_modules\\flow-mono-cli\\.bin\\flow-mono'".
info If you think this is a bug, please open a bug report with the information provided in "...\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

When I look at the file in question, I see a symlink into my cache, which seems wrong:

$ ll node_modules/flow-mono-cli/.bin/
total 0
lrwxrwxrwx 1 ... 197121 154 Nov  1 16:58 flow-mono -> .../AppData/Local/Yarn/Cache/v3/npm-flow-mono-cli-1.4.2-6046938f8125e8eb35fd3ed2a19ab069c601c89e/node_modules/flow-mono-cli/.bin/flow-mono/

And that symlinks to itself, hence the loop:

$ ll '.../AppData/Local/Yarn/Cache/v3/npm-flow-mono-cli-1.4.2-6046938f8125e8eb35fd3ed2a19ab069c601c89e/node_modules/flow-mono-cli/.bin/'
total 0
lrwxrwxrwx 1 ... 197121 154 Nov  1 16:56 flow-mono -> .../AppData/Local/Yarn/Cache/v3/npm-flow-mono-cli-1.4.2-6046938f8125e8eb35fd3ed2a19ab069c601c89e/node_modules/flow-mono-cli/.bin/flow-mono/

If I downgrade to 1.10.1, the problem goes away and yarn install is healthy.

[arcanis]

Interesting - can you open a PR to add a breaking test case to Yarn? I'll see to fix it in the next patch release

[justinmeiners]

@arcanis I cannot allocate time to dive into the project's infrastructure to report an issue. If it wasn't a work project, I would like to :) We will just use an older version until then.

[arcanis]

Will be fixed by #6628, which will likely land in the next patch release.

[achmadk]

Because of this issue, I got an error when generating APK release from React Native project.

[wget]

I have been experiencing this issue on Windows boxes as well. This is not specific to UNIX based OS. The problem was a bit harder to determine on Windows though. When packaging the final apps, the symlinks couldn't be copied and the error message reported by windows was misleading.