Specify custom WebpackDevServer url for webpackHotDevClient

[sktt]

Would you be interested in having the possibility of setting a different url for WebpackDevServer than the current window.location ? see https://github.com/facebookincubator/create-react-app/blob/master/packages/react-dev-utils/webpackHotDevClient.js#L129

In my project I have a different server that serves the react-app bundle. Because of this, I am not able to use webpackHotDevClient with its current configuration. This is because the webpackHotDevClient assumes the app runs from the same location as the WebpackDevServer.

webpack-dev-server/client allows for this by using the magical constant __resourceQuery https://github.com/webpack/webpack-dev-server/blob/master/client/index.js#L22

If you're interested I'd be happy to open a pr for with.

Thank you

[Timer]

Does the advanced configuration section help you? Specifically PUBLIC_URL (and with manual patch #1887 to make it work for development).

Did you try visiting the dev server endpoint instead and using the proxy option?

If one of these don't fulfil your use case, please explain what you are trying to do in more detail (and explain why these existing solutions are not sufficient for you).
We want to have a deep understanding of what you are trying to do before we consider adding any additional configuration.

[sktt]

Hey!
Sorry about that! I will explain to you in detail:

• I have a "Progressive web app", meaning the client bundle is served from a separate server. In development the bundle lives at localhost:3000 and the backend at localhost:3001.
• The server handles a user session! And with each request the user session and other initial data is passed to the app by injecting it in the document. It's done in a way very similar to this.
• If the cookie is not valid or not present the backend redirects to the login page.
• a login causes a hard reload, which then will include the initialData such as the logged in user.

So this probably rules out PUBLIC_URL since as far as i understand that's just for where assets should be served.

The proxy option would have worked if it wasn't for the initial data required to make any api requests. Further it feels kindof awkward and reversed that the dev-server proxies requests to the backend and not the opposite, or maybe that's just me?

So I see two options for my case,

• The client has to request the initial data over xhr and redirect to the login page if there was no valid cookie.
• or that webpackHotDevClient allows me to specify where the dev server actually is!

[Timer]

Is all of this information stored in the cookie? You could use js-cookie.

Optimally, you'd opt for option 1.

The proxy option would have worked if it wasn't for the initial data required to make any api requests.
...
The client has to request the initial data over xhr and redirect to the login page if there was no valid cookie.

A zero-configuration solution is always preferred to a configuration ridden one.
Why not expose an endpoint which gives this information so that it can be fetched if it wasn't injected?

As for "specifying" where the dev server actually is, I'm not sure we want to expose this bit of configuration.

Further it feels kindof awkward and reversed that the dev-server proxies requests to the backend and not the opposite, or maybe that's just me?

Why so? A development server should always proxy off to what it needs IMO.
You shouldn't have you backend proxing to your dev environment because it should be indifferent to its existence.

---

I will /cc @gaearon to see if he has time to provide his opinion on this.

[sktt]

Well it wouldn't be much configuration, only to tell the hotDevClient where the devServer lives.

Using proxy has multiple disadvantages for me. It feels like it was created as a way to have the api on the same origin as the web page. Which is not my case.

It would be a great advantage for me to serve the webpage from my own backend. That way I can have preloaded state and meta tags pre rendered... Using proxy, I'd lose all this functionality only because hotDevClient expects devServer to live at the same origin.

An option could be to have the devServer proxy off calls to anything that isn't the js or css bundle or /socksjs-node. That way I could have the initial document created by my backend as I want.

Thank you!

[viankakrisna]

+1 to this! that way we can add

<script src="http://localhost:3000/static/js/bundle.js"></script>

To the served html at localhost:3001 and still benefit from hot reload and tooling! Not sure how to implement it though, @sktt can you provide a POC? I think this will eliminate the need for #1616

[sktt]

I have a poc in my own private project! I will create one as soon as I have some time over!

Basically I do two things:

1. Replace host and port for /socksjs-node with my devServer
2. Set my publicPath to my devServer, this is hardcoded to / in dev. It has to be updated since it's used to receive the updated ref. see https://github.com/webpack/webpack/blob/54aa3cd0d6167943713491fd5e1110b777336be6/lib/JsonpMainTemplate.runtime.js#L27

Setting publicPath can be done either by modifying it in the webpack config. But it could also be on runtime using __webpack_public_path__ in the entry. For instance one could do

<script data-public-path="http://localhost:3000/" src="http://localhost:3000/static/js/bundle.js"></script>

and in entry

if(document.currentScript.dataset.publicPath) {
  __webpack_public_path__ = document.currentScript.dataset.publicPath
}

and in webpackHotDevClient.js i am assuming that devServer url and publicPath are the same maybe devServer url should be explicit though..

devServerWSS = __webpack_require__.p + '/socksjs-node'

[dburrows]

Can you take a look at #1994 and see if it would solve your problem - I am doing a similar thing and the change in that PR fixed it for me

[sktt]

@dburrows @Timer #1994 indeed implements the key part of the feature I am proposing. However, webpack-dev-server configuration states that.

To teach webpack to make requests (for chunk loading or HMR) to the webpack-dev-server you need to provide a full URL in the output.publicPath option.

See https://webpack.github.io/docs/webpack-dev-server.html#additional-configuration-options

[dburrows]

Aha, ok, I haven't tried chunk loading, will have a look - would definitely be nice to fix it fully.

[gaearon]

I'll close this as stale. We can take PRs that make internals more reusable as long as they don't complicate the ejected code. Other than that it's a bit hard for me to discuss without a very specific proposal in form of a PR.