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

  • My Way into Clojure: Building a Card Game with Om - Part 1

    In order to gain hands-on experiences with functional programming, I wrote an HTML5 card game with Om, a “JavaScript MVC” written in ClojureScript. This first post starts our journey travelling down the Clojure rabbit hole. I'll share my experiences getting started with Clojure, introduce the language's features and explain why its LISP syntax is a logical consequence of its deep infatuation with simplicity.
  • Phase 1: Work | Phase 2: ??? | Phase 3: Profit!

    Wovon profitiert eine Agentur wohl am meisten? Klar, ständig ausgebuchte Entwickler und Designer mit jeweils 8 effektiven Arbeitsstunden am Tag, die möglichst alle beim Kunden abgerechnet werden. Selbst wenn dieses Szenario realistisch wäre, darf bezweifelt werden, ob es der einzige Weg zum blühenden Unternehmen mit einer ansprechenden Kultur ist. Und zum Erfolg.