assets:precompile runs before breakfast:assets:compile

[Freydal]

When I began to deploy to Heroku I found that my breakfast assets were always being update one push behind. I did a little digging in the logs and noticed the asset:precompile was being executed before the breakfast:assets and the new version was not being served.

I was able to find the asset:precompile enhancement in breakfast.rake. I was able to instead prepend the tasks breakfast:yarn:install and breakfast:assets:compile by passing them as an array of strings.

if Rake::Task.task_defined?("assets:precompile")
  Rake::Task["assets:precompile"].enhance ["breakfast:yarn:install", "breakfast:assets:compile"]
end

I also noticed I was having a duplicate yarn install, but I do not know that it was being initiated though breakfast.

Rails 5.1.4

[PatKoperwas]

👍 thank you so much for reporting an issue.

You appear to be right for Rails 5.1 >... I believe that shipped with yarn support built in. I'll take a look later tonight and get a fix out in the next day or two.

[Freydal]

As a workaround I used the following in a intra project rake task.

if Rake::Task.task_defined?("assets:precompile")
  intended_action = Rake::Task["assets:precompile"].actions[0]
  Rake::Task["assets:precompile"].enhance ["breakfast:yarn:install", "breakfast:assets:compile"] do
    intended_action
  end
end

edit: And to add I did need the yarn install. The yarn install I was seeing in heroku was in some other scope or something. Without it brunch wasn't found.

** Thanks for the swift response

[Freydal]

Also if it works for older versions. I think a solid fix would be to pass the two rake task command strings to enhance instead of passing a block with the task object. Although, I'm not sure how older versions will handle it.

[PatKoperwas]

Can you give this branch a shot? https://github.com/devlocker/breakfast/compare/rails-5.1-support

In your Gemfile:

gem "breakfast", github: "devlocker/breakfast", branch: "rails-5.1-support"

# Then run
bundle update breakfast

I realized that if you're on Heroku and followed the directions for deploying to Heroku then you will indeed have yarn run at least twice.

Also, by having Breakfast run it again you miss out on the node_modules cache. So I changed up the the rake task.

However, as a consequence you need to move most of devDependencies in package.json up to the main dependencies section.

Give that a branch a shot - let me know if it works. If it's still funny I can reorder the tasks (so breakfast compiles before the main assets do).

I did notice that Heroku doesn't like to bust their node_modules cache if the only change is moving packages around, so you may need to do this for 1 deploy (to bust the cache).

heroku config:set NODE_MODULES_CACHE=false
git push heroku master
heroku config:set NODE_MODULES_CACHE=true

[Freydal]

I also I created another project using breakfast which reminded me that I had to add the following to assets.rb to get the assets to be found to be served.

Rails.application.config.assets.paths << Rails.root.join('public', 'assets')
Rails.application.config.assets.precompile += %w( app.js app.css )

I will try to check it out when I can circle back to the original project or deploy the newer project to Heroku. I expect there could be an issue if breakfast is compiling after assets.

[Freydal]

I haven't had a chance to try this, but it came to my attention that all of my workarounds were only side effects of my ignorance of the public_file_server config in my production.rb. I was just working around to get assets to compile the brunch output so that I could serve the files. I just needed to set this configuration manually or though env var.
config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present?

[PatKoperwas]

Yes I believe so. I have that set in a few apps I'm running this on.

[PatKoperwas]

Fixed with 0.6.3