HMR not working when devServer is behind a reverse proxy

[bard]

When running the devServer behind a reverse proxy (e.g. in a docker-compose stack that mimicks prod) that exposes a differnt port than the devServer port, the HMR client can no longer connect, because the devServer port gets hardcoded in the HTML:

https://github.com/snowpackjs/snowpack/blob/e040f071164d1f6aa044f8fc7446f08e8719d9b0/snowpack/src/build/build-import-proxy.ts#L105

So if devServer listens on 3000, but is fronted by nginx listening at dev.myapp.127.0.0.1.nip.io on 80, the HMR client is told to connect to dev.myapp.127.0.0.1.nip.io:3000, and fail.

An immediate workaround is to set devOptions: { hmrPort: 0 } to disable the if (hmrPort) conditional, and thus the hardcoding. (It cannot be null or false, config validation wants it to be a number.)

I'm not sure what the purpose of that conditional is, since apparently the WebSocket and the HTTP server are supposed to listen on the same port. If the point is to leave the user the chance to pick a different port, then I think it should rather be something like if (hmrPort && hmrPort !== the_http_server_port).

EDIT: The workaround above (setting hmrPort: 0) appears to not always work. Placing the following early in index.html has been more reliable. It will make window.HMR_WEBSOCKET_PORT read-only and prevent later setting by snowpack.

<script>
    window.__defineGetter__('HMR_WEBSOCKET_PORT', function () { return null })
</script>

[melissamcewen]

Hi @bard I'm not sure the answer here, but I'll post on our Twitter and see if anyone has experience with this.

[bard]

@melissamcewen consider it a bug report more than a question -- I posted here instead of in the Issues because the issue template required to do so.

[jeremycook]

Thanks for the "window.defineGetter..." workaround. It would be nice if there was an official stance on having the snowpack server behind a reverse proxy when developing.