title: Heroku - Build fail "LoadError: canot load such file -- coffee_script"
body: <p>As the title states, I'm unable to complete a build on Heroku after removing <code>gem 'coffee-rails'</code> from my Gemfile. </p>
  
  <p>Below is the error message as well as a few lines before that show that it is removing coffee-script.</p>
  
  <pre><code>remote:        Removing coffee-script (2.4.1)
  remote:        Removing coffee-script-source (1.12.2)
  remote:        Removing coffee-rails (4.2.2)
  remote:        The latest bundler is 2.0.0.pre.3, but you are currently running 1.15.2.
  remote:        To update, run `gem install bundler --pre`
  remote: -----&gt; Installing node-v8.10.0-linux-x64
  remote: -----&gt; Detecting rake tasks
  remote: -----&gt; Preparing app for Rails asset pipeline
  remote:        Running: rake assets:precompile
  remote:        Yarn executable was not detected in the system.
  remote:        Download Yarn at https://yarnpkg.com/en/docs/install
  remote:        rake aborted!
  remote:        LoadError: cannot load such file -- coffee_script
  remote:        /tmp/build_dc46e31874491817c9a77e17cf3ac4d1/vendor/bundle/ruby/2.4.0/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
  </code></pre>
  
  <p>To me, it looks like this could be an issue with Bootsnap on Heroku.</p>
  
  <p>Steps I've taken:</p>
  
  <ol>
  <li>Removed <code>gem 'coffee-rails'</code>   Ran <code>bundle update</code> .</li>
  <li>Removed all references to coffee script per this <a href="https://stackoverflow.com/a/48871341/5491007">answer</a></li>
  <li>Added, committed and pushed the updated Gemfile and Gemfile.lock to my master branch. </li>
  <li>Ran <code>rake tmp:cache:clear</code> on Heroku via bash.   </li>
  <li>Restarted dyno</li>
  </ol>
  
  <p>At this point, I'm tempted to just keep the gem installed as I've confirmed that the build passes.</p>
  
  <p>Any assistance would be wonderful.</p>
  
  <p>Edit: I have staging app setup that had this same issue. Simply starting a new staging app/remote solved the issue, so that's why I'm leaning towards a cache issue.</p>