react-dev-utils/webpackHotDevClient - SockJS - non-customisable host and port

[AlexMiroshnikov]

Hello.

I have a question about the react-dev-utils/webpackHotDevClient.

SockJS there (see https://github.com/facebookincubator/create-react-app/blob/next/packages/react-dev-utils/webpackHotDevClient.js#L64) is instantiated with not customized host and port but with the corresponding parameters of the original window.

Is it intended and/or are there any strict contraindications against customizing host and port?

If yes, what's the explanation?
If not, would it make sense if I handle this issue and make a PR?

Thank you!

[tharakawj]

This is totally intentional. In the given code lines, we are trying to establish a socket connection with webpack dev server which created here to communicate the output of the real-time webpack compiling process. I don't understand why someone needs to customize it.

If you want to customize port and host of the webpack dev server you can easily change them via environment variables.

[AlexMiroshnikov]

@tharakawj
Thank you for reaction.
I do understand what happens on those lines.

If you want to customize port and host of the webpack dev server you can easily change them via environment variables.

Of course I know about this option, and I even use it, but imagine that I have another application which should be able to talk to the webpack dev server. Say, webpack dev server is available by localhost:3000 and I have, for example, anotherapp.local, and I want anotherapp.local to talk to the running webpack dev server, with hot replacement and all that useful things. With the current implementation, if works pretty fine until the moment Sock tries to connect to dev server - instead of establishing connection with localhost:3000, it tries ws://anotherapp.local and, of course, fails.

So why exactly not to customize the parameters?

[tharakawj]

I don't understand why an app needs to connect to webpack dev server of another app. Even though we can technically imagine such scenario, practically it will be a very rare use case.

The core idea of CRA is avoiding configuration and flags to provide the best experience for people getting started with React. So we won't be adding any configuration/customization unless it's a frequent use case.

[AlexMiroshnikov]

Okay, clear.

[CGamesPlay]

Unfortunately, since this won't be fixed, non-CRA users are unable to benefit from react-dev-utils HMR error overlay. Here's some extra information about how this could be fixed if a developer wanted to.

When Webpack needs to refer to other assets via URL, it will use the publicPath to do so. However, react-dev-tools is hardcoded to refer to window.location for this information instead. Among other things, this feature allows non-webpack HTML (e.g. a rails app) to refer to webpack-created assets and have the paths work out correctly. This works for the normal HMR client and doesn't require "special configuration", since it uses the "normal configuration" of publicPath.

[anasanzari]

+1