With `webpack-dev-server` up in one directory, `rails s` in another directory runs without webpack compilation

This probably isn’t a bug but a surprising and (as far as I know) undocumented behavior.

How to reproduce:

  1. Prepare two Rails apps
  2. Run bin/webpack-dev-server in one app (app1)
  3. Run bin/rails s in another app (app2)

We don’t see webpack complication in app2. For example CSS doesn’t apply to app2. I personally prefer getting some warnings from this situation, something like “You’re running webpack-dev-server in somewhere else”.



How does app2 try to connect to webpack? Are they relative to paths?

I would investigate how any Rails.application connects to webpacker, but I’m not sure where to start :thinking:

I was investigating this and app2 doesn’t try to connect to webpack, it only checks if webpack-dev-server is running and if it isn’t running the packs are compiled, if webpack-dev-server is running they aren’t.

Everything starts here (in case of a javascript pack tag) javascript_pack_tag which calls sources_from_manifest_entrypoints which will get the webpacker instance and call lookup_pack_with_chunks! which calls lookup_pack_with_chunks and in this method is the condition compile if compiling?, if compiling? returns true, it means webpack-dev-server isn’t running and it needs to compile the assets, but the compiling? method has this condition config.compile? && !dev_server.running? which means that the config compile needs to be true and the webpack-dev-server shouldn’t be running, but since the method running? from the dev server just checks if he is able to make a tcp connection and when there is another a webpack-dev-server running in another app with the same port as is configured in app2, the connection will be successfull and the assets won’t be compiled.

I don’t know if there is a way to check if the running webpack-dev-server is from another app, well, at least not the way it is currently implemented.

@zzak As I understand Rails doesn’t connects to webpacker, the flow is handled 100% by webpacker when you call any of those helper methods that webpacker exposes.


I’m worried that since webpack is running as an external process it has no idea of the other Rails processes.

One strawman would be to infer they are the same by path, but you could have an app running in some weird location that might cause this logic to break.

It’s probably not up to webpacker to know which Rails app it is supporting in development, or if it already does. We could try to introduce that knowledge to webpacker but I’m not yet familiar enough with it to know the limitations.

Yeah, it really doesn’t have idea of the Rails processes and probably the best solution would be infer if they are on the same path.

What comes to my mind is something like this

stdout_str, status = Open3.capture2 "lsof -i :PORT_CONFIGURED_ON_WEBPACK.yml"
# stdout_str will look something like this
#    node     17692  marcelolx   22u  IPv4  96660      0t0  TCP localhost:3035 (LISTEN)

# here we need to do some trick to get the PID from the previous command output
stdout_str2, status2 = Open3.capture2 "pwdx 17692"
# pwdx stdout_str2 will give us the bellow output
# "17692: /home/marcelolx/webpacker-test-project\n"

then we could compare this path with the current project root path

But I’m not sure how to do this on Windows and I think it would be a better idea just document such behavior.