But I guess since we're just targeting 5.2 and above it makes sense with the changes that are here. Wondering how long yarn install tak will survive in rails itself though 🤔

It seems like 6.5.6 was never published to Rubygems. Is that intentional?

@grncdr Thanks for sharing this.
There were some concerns. It will be released soon.

No problem, I've found a different workaround for my CI, so I'm fine to wait/use a 7.0 beta whenever that's available.

this change breaks the CI pipeline in one of my apps that I upgraded from webpacker to shakapacker (Rails 5 => Rails 7). Why is it considered redundant? I don't have a separate yarn install step in my CI pipeline because until now assets:precompile was triggering it. After upgrading shakapacker from 6.5.4 it stopped working.

So, Rails does not provide this trigger and it was always coming from webpacker/shakapacker.

jsbundling-rails gem supports this by enhancing assets:precompile

if Rake::Task.task_defined?("assets:precompile")
  Rake::Task["assets:precompile"].enhance(["javascript:build"])
end

and as I mentioned, in many cases, e.g. on the AWS Elastic Beanstalk platform this is the desired behaviour. EB invokes assets:precompile automatically for Rails projects, but it won't call yarn install so now the deployments fail with this change in shakapacker (there are workarounds but they should not be necessary)

Honestly, I think this feature should stay (as jsbundling-rails, a solution "competitive/alternative" to shakapacker provides this), but should be controlled with the config option that was present before (webpacker_compile ...), set to false by default

@januszm Is your problem similar to this issue?