Gem::Requirement::BadRequirementError during Heroku deploy

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:

  1. Trying to deploy old commits did not work
  2. 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.

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.

Mehr von uns

Unsere Stories

  • Schluss mit 9 to 5 — Das Fazit unseres Experiments

    Vier Wochen Selbstfindung liegen hinter uns. In dieser Zeit haben wir das Rad nicht neu erfunden, aber entdeckt, wie es für uns runder läuft. Am Ende stehen viele ausgeglichenere Mitarbeiter, ein Plus an Effizienz und neue ToDos auf dem Weg zu einer Arbeitskulktur, die allen genügt
  • Coworking Cologne 2.0

    Coworking has become a known format of teams and individuals working together in a shared space. Driven by its interdisciplinary nature, the mix of people from different professions can enable powerful networking opportunities and open up new ways of acquiring clients or projects. That's why we engaged in coworking right from our start(up).
  • Blockchain untangled I – a basic understanding

    You have heard about blockchain and you might have acquired a rough idea of what it is by now. For most people, the term is not unknown, but most will barely be able to answer the question „what is the blockchain?“ right. After our series of three articles, you most probably will!