Today we noticed that our Heroku deploys for one of our apps was just not working anymore. It is a rails application that we deployed almost daily without any issues since today, and the last commit only contained the addition of a static file and a new rake task. No update of gems, npm packages or anything similar. But we got the following error message:
Gem::Requirement::BadRequirementError: Illformed requirement [">=1 <2"]
/home/bonflintstone/.rvm/gems/ruby-2.5.7/bundler/gems/webpacker-07a62a9dfed3/lib/tasks/webpacker/check_yarn.rake:13:in `new'
/home/bonflintstone/.rvm/gems/ruby-2.5.7/bundler/gems/webpacker-07a62a9dfed3/lib/tasks/webpacker/check_yarn.rake:13:in `block (2 levels) in <top (required)>'
/home/bonflintstone/.rvm/gems/ruby-2.5.7/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
/home/bonflintstone/.rvm/gems/ruby-2.5.7/bin/ruby_executable_hooks:24:in `eval'It seemed to point at some issue with the gem/yarn version. But we could not find any requirement in either gemfile/gemfile.lock or package.json/yarn.lock that was even similar to “>=1 <2”.
While trying out some things we discovered that:
- Trying to deploy old commits did not work
- Locally we were not able to replicate the issue at all…which led to quite a bit frustration.
Finally we noticed that heroku had a message for us in the heroku deploy logs, right before installing the gems:
WARNING:
Removing `Gemfile.lock` because it was generated on Windows.
Bundler will do a full resolve so native gems are handled properly.
This may result in unexpected gem versions being used in your app.
In rare occasions Bundler may not be able to resolve your dependencies at all.
https://devcenter.heroku.com/articles/bundler-windows-gemfile
Alright, since none of us is using windows, there are no \r\n in our gemfile.lock and as platforms we only have ruby. The only possibility we saw was the tzinfo package rails per default includes in new rails apps for windows compatibility.
So we came to the conclusion, that perhaps our local and our production environments were not as similar as we originally thought: If heroku is throwing away the gemfile.lock it could quite possibly be that the gems are newer than what we locally have.
So next thing we tried is updating the gems locally while also removing tzinfo from the gemfile, and voila: We could reproduce the error locally when executing rake webpacker:check_yarn and on Heroku we still got the same error but it was not throwing away our gemfile.lock anymore.
From here it was not that difficult to pin down that the issue was in the fact a new commit on rails/webpacker which broke the package.json engines/yarn version and since our webpacker version point to github instead of the released version of webpacker it broke our deploys. And because of Heroku thinking our gemfile.lock was generated on Windows we were not able to notice this locally. After using the released version of webpacker and a lot of cursing everything was back working as expected.
