Description
The Issue
Currently, no matter what you do with routes and such inside your app, the Webpack node app that does all the hot module reloading and linting and such always wants to serve assets rooted at /. This breaks when a development environment includes more than one interoperating React app sharing a URI path space.
The Proposed Solution
We would really like to be able to serve those assets from a configurable path. It would be nice to be able to specify in our package.json some setting that identified a "mount under" pathspec. I think we can be somewhat flexible about the exact behavior, so long as the asset links Webpack generates contain a configurable path prefix.
The Use Case
We're using create-react-app to build two separate React applications. One application is our domain application. One application is a common user-and-organization management app. The user-and-organization management app is shared with other business units who are using completely separate stacks.
We're still relatively early in the development process, and to date, we've been fine using different ports to route between these apps. However, a new set of requirements requires us to gather the two apps under a single domain name. The user-and-org app should be mounted under domain.name.here/account and the remainder of domain.name.here should serve the domain-specific app.
In production, this shouldn't be a problem. We can emit a bundle that will have the right paths in it by using the homepage setting. We'll stick both bundles onto a CDN; a load balancer will route the API endpoints, and everything should be fine.
In development, things are a little trickier. Webpack's development app always wants to serve assets from /, and it writes all the asset links it emits to reference that path. We can handle getting requests with /account in them to the correct server, and we can write our user-and-org application to expect /account in front of all the routes, but we can't talk Webpack into serving assets under /account -- we could work around this problem -- nor can we get Webpack to emit links to those assets under /account -- and that problem we can't work around.
Workarounds
We've talked about continuing to route by port in development, and just making all our link-generation logic environment sensitive.
We've talked about ejecting and writing our own Webpack config -- we actually started down that path, but I don't think we've reached its conclusion.
We've also pushed back a little harder on using domain names to separate the two apps; that has some upside and some downside, but it obviates this problem.