Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Allow to override host/port for dev server

See original GitHub issue

Is this a bug report?

This is related to #3814

We embedded a CRA-created app within another, larger app and would like to be able to adjust the host/port combination the webpack dev server/client use to connect to each other.

Our use case: the CRA-created app is a new frontend for a part of an existing application and requires authentication to access. Authentication is done via a session / cookie and therefore requests from the CRA-created app are required to send the session cookie alongside. This can be achieved in other ways than living on the same host/port combination as the “host” application but just serving it directly from the “host” application is certainly the easiest way when you don’t have an existing SSO endpoint.

The problem: We run the dev server alongside the “host” application. We access /static/js/bundle.js via http://localhost:3000/static/js/bundle.js in an HTML file served by the “host” application (e.g. on host/port example.com:80). When accessing that HTML file served by the host application, the JS is loaded successfully. It then tries to connect to the webpack dev server on http://example.com/sockjs-node/... which is not working obviously because the dev server is running on localhost:3000.

We can successfully develop using that setup, just the dev server/hot reloading is not working.

I assume this would need one adjustement in react-dev-scripts to accept an env variable to connect to the dev server. Maybe we also need to adjust something based on an env variable in the dev webpack config.

Is this feature out of scope for CRA or would you be open for a PR?

A minimal reproducible example to show this:

create a new CRA app
run yarn start / npm start
create somewhere a new directory with just an index.html containing the following:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <title>React App</title>
</head>
<body>
  <div id="root"></div>
  <script type="text/javascript" src="http://localhost:3000/static/js/bundle.js"></script></body>
</html>

use a static HTML server like serve for that directory and access it.
you’ll notice the react app gets served correctly, webpack-dev-server related requests fail because they go to the wrong host/port combination.

Issue Analytics

State:
Created 5 years ago
Reactions:20
Comments:18

Top GitHub Comments

14reactions

mweibelcommented, May 17, 2018

@miraage I’m aware of HOST and PORT but that doesn’t help in this case. It could be you misunderstood the issue description, I’ll try to explain it differently:

CRA-App is started using npm start listening on http://localhost:3000
Host-App is started, listening on http://example.local
Browser accesses http://example.local/cra-app which contains the HTML I posted above
Browser gets bundle.js from CRA dev server (http://localhost:3000/static/js/bundle.js)
After the bundle is downloaded, it tries to establish a websocket (sockjs) connection to window.location.hostname / window.location.port which is in this case example.local and port 80

Therefore the bundle tries to connect to the wrong host/port combination because the dev server only listens on localhost:3000.

Is this now more easily understandable?

10reactions

wheelibincommented, Sep 28, 2018

Just wanted to leave another vote for this feature.

I’m integrating a CRA app into a .NET MVC app, so like others I am running the app from a different port.

This wouldn’t even have to be configurable, the port in webpackHotDevClient.js just needs to use the same port as the dev server, then it would continue to work for the 99% of users who don’t care about this, and would work for those of us trying to integrate CRA apps into another app.