Webpacker: webpack-dev-server and subdomains (webpacker 3.0)

[aaronsama]

I'm using pow in development to use subdomains on localhost. Since upgrading webpacker to 3.0 I have become unable to use ./bin/webpack-dev-server to serve packs.

Although webpacker correctly detects webpack-dev-server, javascript_pack_tag points to the wrong URL.

My webpacker.yml:

development:
  <<: *default
  compile: true
  inline: true

  dev_server:
    host: myapp.dev
    port: 3035
    hmr: false
    https: true

When I try to load the application from http://subdomain.myapp.dev and I open the Chrome inspector I can see that it's trying to fetch the packs from: http://subdomain.myapp.dev/packs/. The browser simply hangs there and after a while I see the following error in my log:

017-08-31 12:06:59 +0200: Rack app error handling request { GET /packs/react_components-2cc3f4fe216f257545dcdee418efea08.css }
#<Net::ReadTimeout: Net::ReadTimeout>
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/2.3.0/net/protocol.rb:158:in `rbuf_fill'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/2.3.0/net/protocol.rb:136:in `readuntil'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/2.3.0/net/protocol.rb:146:in `readline'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/2.3.0/net/http/response.rb:40:in `read_status_line'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/2.3.0/net/http/response.rb:29:in `read_new'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-proxy-0.6.2/lib/net_http_hacked.rb:53:in `begin_request_hacked'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-proxy-0.6.2/lib/rack/http_streaming_response.rb:60:in `response'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-proxy-0.6.2/lib/rack/http_streaming_response.rb:29:in `headers'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-proxy-0.6.2/lib/rack/proxy.rb:120:in `perform_request'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/webpacker-3.0.0/lib/webpacker/dev_server_proxy.rb:14:in `perform_request'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rack-proxy-0.6.2/lib/rack/proxy.rb:57:in `call'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/newrelic_rpm-4.2.0.334/lib/new_relic/agent/instrumentation/middleware_tracing.rb:92:in `call'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/railties-5.0.2/lib/rails/engine.rb:522:in `call'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/newrelic_rpm-4.2.0.334/lib/new_relic/agent/instrumentation/middleware_tracing.rb:92:in `call'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/puma-3.7.1/lib/puma/configuration.rb:232:in `call'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/puma-3.7.1/lib/puma/server.rb:578:in `handle_request'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/puma-3.7.1/lib/puma/server.rb:415:in `process_client'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/puma-3.7.1/lib/puma/server.rb:275:in `block in run'
/usr/local/opt/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/puma-3.7.1/lib/puma/thread_pool.rb:120:in `block in spawn_thread'

The same happens with HTTPS disabled and with config.x.webpacker[:dev_server_host] = 'https://myapp.dev:3035' in development.rb.

If I disable webpack-dev-server everything works fine but it takes a few second to compile, so it would be ideal to keep using the dev-server.

What could I be doing wrong?

[gauravtiwari]

@aaronsama Just change the host to localhost, under the hood webpacker 3.0.0 uses a middleware to proxy requests to dev server so you don't need to setup anything:

 dev_server:
    host: localhost
    port: 3035
    hmr: false
    https: true

Then start ./bin/webpack-dev-server and all should work. If you get SSL exception please option the dev server link and accept the exception.

[aaronsama]

That works! Thanks @gauravtiwari.

[aaronsama]

It seems that it wasn't working at all. When using the dev-server and localhost as host the stylesheet_pack_tag and javascript_pack_tag helpers generate the wrong digests. If I disable the dev-server everything works as expected.

[gauravtiwari]

@aaronsama You have upgraded the config to latest version right?

[aaronsama]

Yes I did. I even tried reinstalling all webpacker config files from scratch and the result is the same. Now all the packs have a wrong digest and the server returns a 404. With webpacker 2 everything works by setting the host to match pow's but I'm not sure the two things are related.

[gauravtiwari]

@aaronsama Lets investigate together. How are you running dev server? Could you share the output you get when running dev server?

No don't think that's related because the built in proxy forwards the requests to dev server.

[aaronsama]

I can confirm now that the problem is related to subdomains. I temporarily disabled the constraint in my routes and served the app from localhost and everything was working correctly.
The generated digests seem to be correct but the host is somehow wrong.

For example:

• when serving the application from myapp.dev and visiting subdomain.myapp.dev
• <%= javascript_pack_tag 'application' %> becomes <script src="/packs/application-5446a8f57b73f6523425.js"></script> which triggers a request to http://subdomain.myapp.dev/packs/application-5446a8f57b73f6523425.js. This results in a 404.
• However, if I visit http://localhost:3035/packs/application-5446a8f57b73f6523425.js I can see the file's source.

This is the output of running bin/webpack-dev-server

 10% building modules 4/4 modules 0 active
Project is running at http://localhost:3035/
webpack output is served from /packs/
Content not from webpack is served from <omissis>/public/packs
404s will fallback to /index.html
Hash: 5b74f4a588fe7341efab
Version: webpack 3.5.5
Time: 21365ms
...
# compilation stuff
...
webpack: Compiled successfully.

[gauravtiwari]

Ahh I see and it works if you just browse the app on myapp.dev without subdomain constraint?

[aaronsama]

No. It doesn't. It works only if I visit localhost:port.

[gauravtiwari]

Just reproduced the problem you are experiencing, investigating...

[gauravtiwari]

Fixed in #730

[gauravtiwari]

@aaronsama Just released 3.0.1 with fix

[aaronsama]

Awesome! Updating my Gemfile ASAP