Webpacker: `webpacker:compile` executes before or after `assets:precompile`

Created on 11 Mar 2017  ·  36Comments  ·  Source: rails/webpacker

Hello, I'm working on getting webpacker supported on Heroku. I see this warning when running rake assets:precompile on an app.

I, [2017-03-11T00:08:01.980134 #1188]  INFO -- : Didn't find any digests file at /tmp/build_e690a85412228cbd44c858dcaab50841/public/packs/digests.json. You must first compile the packs via rails webpacker:compile

Is webpacker:compile meant to run after or before assets:precompile? The code and comment suggest this isn't the case.

Most helpful comment

For clarity @hone and I work for Heroku. We are the Ruby buildpack maintainers. We want to make sure that webpacker and Rails 5.1 play nice on heroku. When I say "branch" I am referring to a branch of the buildpack that installs yarn https://github.com/heroku/heroku-buildpack-ruby/pull/540.

All 36 comments

@hone This is OK, because the digests.json is produced after the webpacker:compile is run so, it will log that message anyway regardless whether it's runs before or after. In this case, it runs after assets are compiled. Here is the source - https://github.com/rails/webpacker/blob/master/lib/webpacker/digests.rb#L38

@gauravtiwari we need to not error or warn when people are using the software correctly. Otherwise when 5.1 is released there will be dozens or hundreds of issues opened about the warning and it will be a bad experience for the end user. We also need to verify the current software is correct.

@schneems I agree :) the warning is actually pointless now but perhaps, earlier it was needed. I think this will go away in stable 1.0 as there are some additions on way that will change the way this is handled. Perhaps someone from webpacker/rails core team can verify.

I have commit to Rails. Terence posted because the behavior was unclear. I posted because it is still unclear.

@schneems thanks for pointing this out. I think @gauravtiwari has acknowledged with agreement. Making it "go away" is a common goal.

It's not the first time we tried addressing this warning. It was briefly mentioned at https://github.com/rails/webpacker/issues/116 too

Moving forward, we can remove/replace that warning if it's no longer relevant (Is this true?) Anyone, please feel free to make suggestion so that a PR can be made to fix this.

Just to add on, I tried deploying a new rails with --webpack=vue --database=postgresql and heroku buildpacks:set heroku/nodejs --index 1 and heroku buildpacks:set heroku/ruby --index 2. Deployment works but app crashed without any hint. Perhaps there are other critical issues to be fixed here? @gauravtiwari have you deployed to heroku recently? successful?

@ytbryan No don't think this is relevant anymore and I will get rid of it in #153, with new manifest generation plugin.

For heroku I think the vue option added sass loader, which needs node-sass, but I think that's installed on heroku. If you manually add node sass and add post install hook under scripts to rebuild node-sass, within your package.json I think it will deploy fine.

Let me know if this works.

Ohh the deployment works?did you tailed the logs - heroku logs -t to see why it's failing?

Sorry, didn't had time to investigate just now. But seems this might be the fix http://stackoverflow.com/a/15693371/388280 (I might have missed it, can we set the port to fix Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch ?)

I think node-sass is already included -> https://github.com/rails/webpacker/blob/master/lib/tasks/installers/vue.rake#L43

@gauravtiwari Do you have a working repo that you used to deploy to heroku on github?

2017-03-14T03:14:10.291163+00:00 app[web.1]: => Booting Puma
2017-03-14T03:14:10.291176+00:00 app[web.1]: => Run `rails server -h` for more startup options
2017-03-14T03:14:10.291175+00:00 app[web.1]: => Rails 5.1.0.beta1 application starting in production on http://localhost:56335
2017-03-14T03:14:10.291177+00:00 app[web.1]: Puma starting in single mode...
2017-03-14T03:14:10.291181+00:00 app[web.1]: * Version 3.8.1 (ruby 2.2.6-p396), codename: Sassy Salamander
2017-03-14T03:14:10.291182+00:00 app[web.1]: * Min threads: 5, max threads: 5
2017-03-14T03:14:10.291184+00:00 app[web.1]: * Environment: production
2017-03-14T03:14:10.291315+00:00 app[web.1]: * Listening on tcp://localhost:56335
2017-03-14T03:14:10.292146+00:00 app[web.1]: Use Ctrl-C to stop
2017-03-14T03:15:05.427193+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2017-03-14T03:15:05.427293+00:00 heroku[web.1]: Stopping process with SIGKILL
2017-03-14T03:15:05.547843+00:00 heroku[web.1]: Process exited with status 137
2017-03-14T03:15:05.561391+00:00 heroku[web.1]: State changed from starting to crashed

Here's a bare bones example app I made https://github.com/schneems/rails51_webpacker

We don't have yarn installed on Heroku yet for Ruby apps, you have to use @hone's brach or wait a day or two and use master. That being said, I would expect the deploy to fail instead of the server failing to boot.

@schneems Just to be clear, Rails apps with webpacker do not have a straightforward method to deploy? Not sure what branch you are referring to when you say @hone's branch. Any insight?

For clarity @hone and I work for Heroku. We are the Ruby buildpack maintainers. We want to make sure that webpacker and Rails 5.1 play nice on heroku. When I say "branch" I am referring to a branch of the buildpack that installs yarn https://github.com/heroku/heroku-buildpack-ruby/pull/540.

@ytbryan Ohh, you seem to binding to localhost. It should be web: bundle exec puma -p $PORT or with rails server specify -b option with 0.0.0.0

Here is one, but using the latest feature branch - https://github.com/gauravtiwari/webpacker-demo-app

@schneems Just to confirm this warning will go away once #153 is merged.

Awesome, BTW we released support for Yarn https://devcenter.heroku.com/changelog-items/1114

Also that puma not booting problem is a bug in Rails. It's fixed on master but i documented a way around it in my changelog entry.

That's awesome, no need of node build pack anymore. Great, actually I saw this behaviour a while ago but didn't realise it could be a bug. Thank you :)

I think it still require buildpack https://devcenter.heroku.com/articles/ruby-support#installed-binaries

Great, thanks Richard!

@schneems Just noticed while deploying a webpacker app that, buildpack installs yarn, but doesn't run yarn install afterwards like bundle install. Could you please test this with a new rails app with webpacker?

screen shot 2017-03-17 at 07 47 30

@gauravtiwari I used this app as a test. Does webpacker not call yarn install anymore? This is what I see:

remote: -----> Installing node-v6.10.0-linux-x64
remote: -----> Installing yarn-0.22.0
remote: -----> Detecting rake tasks
remote: -----> Preparing app for Rails asset pipeline
remote:        Running: rake assets:precompile
remote:        I, [2017-03-15T20:09:53.526602 #413]  INFO -- : Didn't find any digests file at /tmp/build_ea8c8655b3a069f74edc0cbe81285af7/public/packs/digests.json. You must first compile the packs via rails webpacker:compile
remote:        yarn install v0.22.0
remote:        [1/4] Resolving packages...
remote:        [2/4] Fetching packages...
remote:        warning [email protected]: The platform "linux" is incompatible with this module.
remote:        info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
remote:        [3/4] Linking dependencies...
remote:        [4/4] Building fresh packages...
remote:        Done in 25.22s.
remote:        (node:869) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see https://github.com/webpack/loader-utils/issues/56
remote:        parseQuery() will be replaced with getOptions() in the next major version of loader-utils.
remote:        Compiled digests for all packs in /tmp/build_ea8c8655b3a069f74edc0cbe81285af7/public/packs/digests.json:
remote:        {"application":"application-52d19136d5660afd39af.js"}
remote:        Asset precompilation completed (28.33s)
remote:        Cleaning assets
remote:        Running: rake assets:clean

@hone Nope, internally webpacker doesn't call yarn install, just enhances assets:precompile with webpacker:compile. I guess this app is also using nodejs buildpack. Nodejs buildpack does run yarn install if used alongside ruby. Perhaps, it makes sense to add this to the buildpack instead, if used with webpacker?

@gauravtiwari I just tested a fresh Rails 5.1 app and yarn install was run inside the assets:precompile task. On none of these apps have I set the node buildpack b/c that would defeat the whole point. /cc @guilleiguaran

The screenshot I posted before do not use any buildpack, just simple git push heroku master

is that code available somewhere?

Ahh right. Let me try again.

:+1: thanks for your help and testing this before RC1 lands :heart:

No worries @hone ❤️ This is the one I am deploying. Actually someone else had another issue whilst deploying to heroku, so this is a fork that fixes it - https://github.com/gauravtiwari/webpacker-erb-heroku. This is what I get -

screen shot 2017-03-18 at 07 38 28

screen shot 2017-03-18 at 07 39 05

screen shot 2017-03-18 at 07 39 12

Obviously when I set the build-packs manually then all works -

screen shot 2017-03-18 at 07 41 25

screen shot 2017-03-18 at 07 41 41

screen shot 2017-03-18 at 07 42 26

@gauravtiwari weird. i wonder if there's something in rails 5.1 that runs yarn install? I'll have to investigate later or have @schneems do it. It's almost 3am here :(

@hone Ohh yes, my bad I should have suspected that. It's definitely 5.1 - https://github.com/rails/rails/commit/b1c08d8d9b921fdcf3813b5c20a0c3fab96eccca

@gauravtiwari :+1: mystery solved. That being said, it would be nice to probably make this work for webpacker standalone or we should pull that from Rails into here?

@hone Ohh, that's too late. Alright, I won't pester you, talk later 👍

@hone I think it makes sense to add a standalone yarn installer for webpacker to make it compatible with other Rails version. Seems like that's the only missing piece.

cool. so implement the rails equiv in webpacker itself?

On 20/03/17 11:23, Gaurav Tiwari wrote:

@hone https://github.com/hone I think it makes sense to add a
standalone yarn installer for webpacker to make it compatible with other
Rails version. Seems like that's the only missing piece.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rails/webpacker/issues/169#issuecomment-287813791,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABASeZyGPNnxAx3lL5Q7MfzKD0rloD1ks5rnqf8gaJpZM4MaBLN.

Yes, that's the plan. I can make a PR once #153 is merged.

Btw @hone @schneems Should we also install npm as well if webpacker is used alongside yarn on Heroku? Seems like, if folks are using node with yarn, they might need or use npm in some cases. For ex - npm rebuild node-sass

@hone this can be closed. #153 is merged

Was this page helpful?
0 / 5 - 0 ratings