Repository navigation
react-dev-utils/webpackHotDevClient - SockJS - non-customisable host and port #3814
Description
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!
Activity
tharakawj commentedon Jan 16, 2018
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 commentedon Jan 16, 2018
@tharakawj
Thank you for reaction.
I do understand what happens on those lines.
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:3000and I have, for example,anotherapp.local, and I wantanotherapp.localto 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 withlocalhost:3000, it triesws://anotherapp.localand, of course, fails.So why exactly not to customize the parameters?
tharakawj commentedon Jan 17, 2018
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 commentedon Jan 18, 2018
Okay, clear.
CGamesPlay commentedon Mar 2, 2018
Unfortunately, since this won't be fixed, non-CRA users are unable to benefit from
react-dev-utilsHMR 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
publicPathto do so. However,react-dev-toolsis hardcoded to refer towindow.locationfor 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" ofpublicPath.Make socket url configurable via env
anasanzari commentedon Jan 14, 2019
+1