Causes Issues with Yarn shims

[westonganger]

This plugin was causing problems with yarn making it unusable

rbenv: yarn: command not found

I stumbled across rbenv/rbenv#1051 (comment) in which someone commented to remove this plugin and it fixes the problem

Sure enough, removing this plugin rm -rf ~/.rbenv/plugins/rbenv-binstubs fixed the issue immediately. In my case I am using OSX Sierra but this fix could likely apply to other systems.

[mrhead]

I'm having exactly the same issue and while I was googling it I came here.

@westonganger Did you try to debug it? Did you find any solution?

[westonganger]

Nope I just removed the plugin. TBH I dont like yarn anyways but its required for some stuff still. Would much prefer to continue using this plugin if a fix is made.

[mrhead]

I did some debugging and I found out that if you did not generate binstubs for your project, then rbenv-binstubs generates shims for all files in ~/your_project/bin. So if you have a new rails application which contains bin/yarn and you did not generate binstubs for it, then this plugin will generate a shim for yarn.

I'm not sure if this plugin should do it or not, but you can avoid it by generating binstubs for all of your projects with:

bundle install --binstubs .bundle/bin

Once you do it the issue with the yarn shim disappears.

Btw. this is mentioned also in the README of this project but I never paid attention to it.

[madumlao]

Yes, rbenv-binstubs was specifically designed to work with binstubs generated by bundler, whose default path is set to ./bin:

From https://bundler.io/man/bundle-binstubs.1.html

Binstubs are scripts that wrap around executables. Bundler creates a small Ruby file (a binstub) that loads Bundler, runs the command, and puts it into bin/. Binstubs are a shortcut-or alternative- to always using bundle exec.

This is unless BUNDLE_BIN is set. This tells bundler (and rbenv-binstubs) where to put / find executables.

Usually, when I use rbenv-binstubs, I also configure bundler as follows:

bundle config --global path .bundle
bundle config --global bin .bundle/bin

which makes all projects have completely isolated gems and binstubs in their .bundle/bin directory OR specifically invoke the bundler command to set the binstubs path.

There may be some value in having the plugin detect whether a binstub is a ruby executable or not before generating shims. I did this specifically for pyenv-binstubs and may consider implementing here, but it's at the bottom of my priorities. Also, I'm not sure if bundler also puts compiled executables in the binstub path, in which case, I wouldn't know how to handle it.

[madumlao]

This issue should be resolved in madumlao/rbenv-binstubs@335a830 (master branch). rbenv-binstubs will now only shim / inject ruby executables. Would appreciate if you checked it out!

[mrhead]

Thank you @madumlao!

Unfortunately I'm not able to reproduce the original issue anymore so I can't test if the new version fixes it.

[jasonkarns]

@madumlao I'm curious about your implementation. The yarn binstub that ships with Rails (or is generated by Rails, rather) is a ruby binstub:

$ head -1 bin/yarn 
#!/usr/bin/env ruby

Did this not used to be the case? Or is there something else about your implementation that I'm missing?

I suspect the former, and that this patch is no longer necessary for yarn in particular, but would be necessary for any other bin/* utility that isn't a ruby executable?

[madumlao]

@jasonkarns , that's weird. Rails should NOT be either shipping with, generating, or stubbing yarn. I also checked my old rails projects and they don't stub yarn either. Yarn is not a rails utility and this might cause serious issues with users of nodenv / nenv.

[jasonkarns]

The yarn binstub was first introduced in Dec 2016: rails/rails@3dac36b#diff-835c0a70de9cf02b472c84bf0a72323a and later renamed as a .tt template: rails/rails@8dd76a7#diff-de7ecbe89c4176f75b702a1db707794b

[madumlao]

@jasonkarns , since I encountered a similar issue in nenv because the node community just LOVES creating executables that "shadow" system executables. So, I've tried a different tack in madumlao/rbenv-binstubs/unshadow . This is also merged into madumlao/rbenv-binstubs/master

rbenv-binstubs will actively "unshim" if no binstubs are pointed to by any shimmed executables, thus defaulting to whatever system or user-defined paths are defined.

This should solve the case where yarn being shimmed inside the project path of one ruby project causes yarn to break everywhere else (rbenv will not use the shim if the yarn executable pointed to by the shim does not exist). However, inside the project path of that ruby project, the yarn shim will still be used. This does not resolve any issues caused by that yarn shim being broken (if it is broken).