-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Do not run yarn install on every assets:precompile #405
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
IMHO dealing |
I tried working around this using the same workaround described at #440, but for some reason the Rake is confusing :( |
Afaik this is the line that does it: https://github.com/rails/webpacker/blob/master/lib/tasks/webpacker/compile.rake#L32 It also checks for something present in Rails 5.1, and I do wonder if Rails 5.1 also commits this mistake or not? |
@Gargron Yep it's there too - 5.1+ |
See also: rails/webpacker#405 Yarn just like bundler is usually run explicitly and only when dependencies are updated. Invoking yarn on every asset precompilation is unnecessary, it can also be problematic if you've cleaned yarn cache prior because you have everything you need, yarn install would also run any post-install scripts regardless of whether any new dependencies had to actually be installed or not
Since they check if the
|
@wagoid Hmm.. for me that runs both my workaround task and the existing task... |
@wagoid, I also tried your workaround, only to find that it still runs the existing task. 🙁 I'm glad you offered an attempt though. 👍 So does anyone have another workaround? I'm stuck. Thanks! |
Yeah, I thought that worked at first but it didn't :( |
@wagoid thanks for chiming in about your results too. |
I'm having weird issues on Heroku with Rails 5.1, webpacker 3.0.1, and the nodejs + ruby buildpacks. Whenever I deploy, the nodejs buildpack will run I've been banging my head against the wall trying to get this to just download packages a single time and cache them between builds, but no luck. Anyone else have a similar issue or fix? I wish I could just |
Is NODE_MODULES_CACHE set to true? See here: https://devcenter.heroku.com/articles/nodejs-support#cache-behavior |
Deleting bin/yarn in the app will disable yarn |
@gauravtiwari yeah it's set to true!
@shaicoleman Interesting… I will go down this path and see what happens. |
I also came to this issue when trying to deploy to Heroku. I just tried setting NODE_MODULES_CACHE to true and deleting bin/yarn, but neither worked for me. |
@gutierlf I got it to work by deleting I'm using the
When my As well, I'm setting explicit versions in my {
"engines": {
"node": "8.5.0",
"npm": "5.3.0",
"yarn": "^1.0.2"
}
} I had to move some babel plugins from Let me know if this info helps. |
@dbalatero thanks for sharing so many details about what worked for you. I'll try later on and hopefully have the same success you did. In any case, I'll report back. |
Ok, my Heroku deploy is working now 🎉, but I'm not sure which was the change that really fixed things 🤔. Following @dbalatero's advice, I set the five vars and used the My current guess is that it has to do with the Anyhow, thanks @dbalatero. |
@gutierlf glad to hear it's working! What I'd love to be able to do is only use the This might be getting off topic though at this point… |
FWIW, I was able to bypass webpacker's compile-related tasks (and underlying hard dependency on yarn) by simply making my own task derived from webpacker's and setting the environment variable WEBPACKER_PRECOMPILE to false. Rake::Task["assets:precompile"].enhance do
$stdout.sync = true
def ensure_log_goes_to_stdout
old_logger = Webpacker.logger
Webpacker.logger = ActiveSupport::Logger.new(STDOUT)
yield
ensure
Webpacker.logger = old_logger
end
namespace :webpacker do
desc "Compile JavaScript packs using webpack for production with digests"
task custom_compile: :environment do
ensure_log_goes_to_stdout do
if Webpacker.compile
# Successful compilation!
else
# Failed compilation
exit!
end
end
end
end
Rake::Task["webpacker:custom_compile"].invoke
end Granted, this (as well as some other approaches I've come across) aren't what I would call ideal, but I believe that the risk is fairly low:
|
Thank you @wagoid and @shaicoleman , it worked! <3 |
The way to nullify an existing rake task prior to redefinition (which otherwise appends, as commenters found out) is: Rake::Task["yarn:install"].clear |
I'm having this problem in Rails 6 pre. Why is yarn:install called at all when precompilng assets? PS. Working workaround (to be added at the end of a Rakefile):
|
@swistak Did you tried to just remove |
But I need a yarn to in a project and I'm installing it in a different step with custom flags. |
For anyone coming across this today:
This works for our deployment scheme by |
Was this ever fixed? The workarounds don't work, the precompile task even fails to start because of |
setting NODE_ENV='development' fixed the problem when running yarn install and getting all necessary dev dependencies. Not sure this is the solution for your problem. But it helped me solve a similar one and hope it helps somebody else |
I was able to make it work on Rails 5.2.4.4 and webpacker 4.2.2 with: # Someone decided to install yarn every time asset:precompile is called for some strange reason.
# It's less then optimal - as it prevents us from doing it in a separate step during deploy with specific options.
# So we clear the old task and override it with an empty one.
if ENV['SKIP_YARN_INSTALL_ON_PRECOMPILE']
Rails.application.config.after_initialize do
Rake::Task['webpacker:yarn_install'].clear
namespace :webpacker do
task :yarn_install do
end
end
Rake::Task['yarn:install'].clear
namespace :yarn do
task :install do
end
end
end
Rake::Task.define_task("assets:precompile" => ["webpacker:compile"])
end |
Any news on this guys? @badosu nice work! |
Instead of defining various tasks as "empty", we can surgically remove # Rakefile
t = Rake::Task['assets:precompile']
deps = t.prerequisites.dup # ["webpacker:yarn_install", "webpacker:compile"]
t.clear_prerequisites
t.enhance(deps - ['webpacker:yarn_install']) It seems worthwhile to be surgical here, in case webpacker adds other prerequisites in the future. Tested with:
|
Uhhh, you shouldn't be redefining |
After upgrading Webpacker to 5.4 with rails 6.0 I had problems with the workaround of clearing the task yarn:install. It started throwing the error Did this task stop being defined? |
Seems like it is enough now ( The task looks like it's defined though, but it's loaded after your rake task so you cannot delete it at that point. |
By default `bin/rails assets:precompile` will run `yarn install` again. The suggested workaround is to remove `bin/yarn` before running the task. See rails/webpacker#405
By default `bin/rails assets:precompile` will run `yarn install` again. The suggested workaround is to remove `bin/yarn` before running the task. See rails/webpacker#405
By default `bin/rails assets:precompile` will run `yarn install` again. The suggested workaround is to remove `bin/yarn` before running the task. See rails/webpacker#405
By default `bin/rails assets:precompile` will run `yarn install` again. The suggested workaround is to remove `bin/yarn` before running the task. See rails/webpacker#405
By default `bin/rails assets:precompile` will run `yarn install` again. The suggested workaround is to remove `bin/yarn` before running the task. See rails/webpacker#405
Why was this closed? |
https://github.com/rails/webpacker/#webpacker-has-been-retired- |
Adding this here in case others are coming from search engines: there is a
|
Previously it was run automatically during theme:preprocess (twice) and also during deploy:assets:precompile. See rails/webpacker#405 for more details.
At least add an option to disable that behaviour. Usually you have a separate step for making sure bundler/yarn dependencies are installed - I'd say in most cases. So this invocation is just wasting a few seconds in the best case, and in the worst case as I'm experiencing right now it's triggering post-install scripts every time.
The text was updated successfully, but these errors were encountered: