Webpacker binstubs not installing correctly - ruby-on-rails

I have a perplexing issue here when trying to implement the Rails Webpacker gem into an existing application.
Unfortunately, I do not have much to offer in the way of debugging information, this is also an internal project, so I have limited options in terms of sharing the entire project source.
I am following the exact steps outlined here: https://github.com/rails/webpacker and have done it multiple times now, but during the bundle exec rails webpacker:install command (after running bundle), I see the message:
Skipped webpack and webpack-dev-server since they already exist.
If you want to overwrite skipped stubs, use --force.
This binstubs most-definitely do not exist in my bin/ directory. Either before or after the webpacker install.
I feel like I have tried everything at this point, and nothing seems to be working:
Reinstalling the gem (multiple versions, even via Git)
Manually creating the binstub from a different project (this "worked" until I tried to run the webpacker:install:react script).
Manually running Yarn, attempting to --force create the binstubs
Tried multiple different configuration tweaks in webpacker.yml
I am just out of ideas at this point. Anything else I should be checking, could try?

This is a fix that worked for me:
I copied these two files into the bin directory of my app and then bundle exec rails webpacker:check_binstubs stopped complaining.
As a side effect it made my app deployable on my Paas with the standard buildpack.

Related

Heroku deploy fails to load custom .bundle file

I'm having a lot of trouble googling this issue, as bundler keeps coming up. However, my issue is with a c library that I've bundled using mkmf and the ruby c api. I've compiled my c code into a file (e.g. my_library.bundle) and I've required it inside a helper with require_relative "my_library" without a problem.
The problem arrises when I deploy to heroku and I get the error:
2019-08-14T19:09:15.452530+00:00 app[web.1]: /app/vendor/bundle/ruby/2.6.0/gems/bootsnap-1.4.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require': cannot load such file -- /app/app/helpers/my_library (LoadError)
I can run ls and cat on my heroku app to verify the file is there and the contents match. When I run the application locally with RAILS_ENV=production, I also don't run into any issues. Also, running heroku local web runs fine on my machine.
Does this have something to do with my configs autoload_paths? My main issue is that I can't seem to debug this locally.
EDIT:
I've noticed that this problem arrises in dockerized instances, as well. It seems that something about containerization seems to be the problem. I've even tried creating a gem to contain the bundle following this guide, which works locally, but again has the same issue finding the file, but this time the path is relative to the gem, not my project. I'm still stumped on what is causing this issue.
According to the error that you posted, it seems that Docker doesn't point to the correct path cannot load such file -- /app/app/helpers/my_library. If that is correct, you should explicitly specify the working directory in your Dockerfile.
WORKDIR /path/to/project
After that, just rebuild the image.
Now, if this doesn't work, you can check autoload_paths in your project or customize bootsnap to avoid error in autoloading paths.
What you can do is have the entire my_library as a local gem and point your Gemfile to it.
Roughly, the outline would be as follows:
Place the entire code for my_library in directory within your app, say fixtures (which is at the same level as your Gemfile.)
app/
...
fixtures/
my_library/
ext/
...
lib/
...
my_library.gemspec
Rakefile
Gemfile
Point your Gemfile to the my_library gem:
gem 'my_library', path: 'fixtures/my_library'
Then simply update your Gemfile.lock by running
bundle update
As #jay-dorsey mentioned, the bundle did need to be compiled on the server that was deploying the application in order to be used. Both of the guides that I followed to create the gem had some misinformation.
The gem should contain only the source files, no compiled source files
The rakefile should reference ext.lib_dir = "lib/my_library" instead of the ext directory
The gemspec should add the rake-compiler development dependency BEFORE the other dependencies
The version files should NOT try to load the extension, as it's being used in the gemspec, which is called before the gem has a chance to be compiled by rake / bundler
.bundle files can't be read on linux machines

Running rails from a different bundle folder

For debugging purposes, I installed bundle gems into a different folder
bundle install --path=.bundle
I want to debug the app modifying the gem sources in this folder, so I need to run my server, and tell rails to use the gems in the special folder
What options do I need to add to rails server in order to produce the desired magic?
How do you do when you need to debug a problem or a mysterious, cryptic behaviour in your rails app that doesn't seem to be due to your codebase?
More precisely, what is the recommended strategy for debugging a gem?

Bundler is using a binstub that was created for a different gem.

When I run a rails console using
rails console
everything is fine.
When I run a rails console using
bundle exec rails console
I get the following warning
Bundler is using a binstub that was created for a different gem.
This is deprecated, in future versions you may need to `bundle binstub my_gem` to work around a system/bundle conflict.
my_gem happens to be a gem that I've created that is completely unrelated and not used in the current project directory.
I've tried every solution in this question with no luck:
Bundler is using a binstub that was created for a different gem
I would appreciate any guidance on removing this warning or help understanding how binstubs work so that I can figure out what's going on.
Nowadays it's common for projects to have "specialized" versions of tools. E.g. in some projects the "rails" command may be expected to be run using "spring" (to start up faster).
So it's not uncommon to generate files in your project's 'bin' directory, and then use those versions when running commands, so e.g. instead of
bundle exec rails console
or
bundle exec spring rails console
you could simply expect the following to work correctly
bin/rails console
and not care whether the project needs spring or bundler or zeus or whatever.
So if you don't have 'bin/rails' in your project, you should generate one that suits the project, e.g. using
bin/rake rails:update:bin
If you don't already have bin/rake, you might have to use
bundle exec rake rails:update:bin
(so your bin/rake commands will also get a speedup from using spring)
Some people even put ./bin in their paths, so whenever they run rake (or whatever) they are actually running ./bin/rake if it exists.
Troubleshooting
for project specific tasks, use bin/* files, creating them if needed (e.g. using special rake tasks like in Rails or using bundle binstub <gemname>) - usually those have Bundler specific lines that will make Bundler happy.
for non-project gems (like your gem), find out where it is (e.g. which mygem) and check out it's contents - it's probably using e.g. "bundler/setup" which is confusing Bundler (because bundler expects a local Gemfile file). Maybe your gem is using bundler (it shouldn't if it's a "global" kind of tool and not a "project" tool).
Also, if you're using them, check if tools like RVM and .rbenv are correctly adding their stuff to your bin files (they usually need to setup specific paths)
If you still have questions, it's best to post the contents of the bin file causing problems - it's meant to be a plain Ruby file, so if there's something wrong, it's usually because of the file contents (and not anything else).
More info: https://github.com/sstephenson/rbenv/wiki/Understanding-binstubs
It happened in a project of mine. Because I ran bundle install with another ruby version.
Make sure your rvm is the correctly ruby version.

Files added to my Ruby Project when using RBENV

After installing RBEnv and rebuilding my ROR project, I now seem to have added many, many files to my project. They are in /vendor/local, and appear to duplicate what you would normally find in /Library/Ruby/Gems.
My project will not run without these files present (I get the message Could not find rake-0.9.2.2 in any of the sources.
I had difficulties with my RBEnv installation. I have what I suspect are other issues (like I have to bundle exec rails instead of just running rails). I suspect that I have done something wrong and should not have these files in my project. What I'd like to know is:
1) Should these files be there?
2) How best to fix this (if this is not how it is supposed to work)?
3) If the best approach is to start over and reinstall rbenv, how do I clear it all out?
It is true that using RBENV will end up putting copies of your gems in the project's /vendor/local folder. This is to remove any dependencies on your base gem set. These files need not be part of your source repository, as long as your 'gemfile' and your '.rbenv-version' file are included in the repository.
Another price you pay for using rbenv is that you must bundle exec rails <command> and bundle exec rake <command> from here on in.

Capistrano user-related problem

I'm deploying a rails application using Capistrano to a shared server (on WebFaction). This means there are several different Ruby version installed there.
Everything works fine until I want to run some rake tasks. These tasks fail by saying I don't have the right RubyGems version.
From this thread I understood that fixing it would be as easy as adding the full path to the correct rake folder to my rake commands. I tried that but failed again, now because the Ruby interpreter that is used is the wrong one.
I assumed that capistrano would use the username/password I gave it to run commands on the server but it seems not to be the case.
Am I missing something? How can I fix that?
Thanks!
This is indeed a path issue. I solved it by symlinking my ruby, rake, and rails executables to my path. For instance, if the executables that you want (but are failing to work) are located at /opt/ruby/bin/ruby, you'll symlink it to:
ln -s /opt/ruby/bin/ruby /usr/local/bin/ruby

Resources