Use same port as the dev server for HMR

[etamponi]

🙋 feature request

Serve the HMR websocket on the same port that the development server uses.

🤔 Expected Behavior

There should be no need to use two distinct ports (at least from an end-user prospective). It would be great to have at least a option to enable the use of the same port for both the dev server and HMR:

parcel --proxy-hmr src/index.html

which will serve the HMR websocket on port 1234 (or on any port specified by --port)

😯 Current Behavior

Right now, the HMR websocket server listens on a different port and there is no way to use the same port as the development server.

💁 Possible Solution

Either by default or under an option like --proxy-hmr, websocket connections get proxied by the development server to the HMR server, allowing the client side to use the same port as the develpopment server to get HMR.

I'll try to create a PR 🤞

🔦 Context

Right now, the HMR websocket server listens on a different port, which means that services like Glitch (https://glitch.com, I am one of the core developers) cannot use Parcel's HMR. We are going to deploy a change that will enable us to use parcel watch (we used to use safe-write, so it didn't work), but it would be awesome if we could also use the parcel development server with HMR!!!

Example:

This Glitch project: https://glitch.com/edit/#!/parcel uses an hack and a proxy to get the HMR running on the same port. It works great!

[benduran]

Was just about to submit this as a new feature, but I see this is still open. Any word from the development team about this?

It would be great if we could opt-in to using the same port and host for both the HMR / Live Reload server and the static server. This is especially useful in enterprise software applications that require mocking an SSO provider during local development. Typically, these mocks are Docker containers or small CLI tools that act as a reverse proxy and aid in providing user identity during local development, and are typically less configurable that the build tools we UI / Front-end engineers are using.

[benduran]

There are easy-ish ways to address this, thanks to Parcel's easy-to-use Node API. However, it would be fantastic if it was provided out-of-the-box for a truly drop-in bundler.

[benduran]

@DeMoorJasper and @devongovett I hate to be a bother, but just wanted to bring this more to your attention. I'm trying to get more devs on board to use Parcel at my company, and while we have a partial workaround for this, it would be nice to reduce local dev code to not need browser-sync to support live reloading.

If this is planned for Parcel 2, please let me know so I can relay the message. I'd be more than happy to help out, as well, if it's a resourcing issue. Thanks!

[devongovett]

What’s the reasoning for needing the same port? Just to avoid opening multiple ports in docker or something else?

In Parcel 2 this might actually be more difficult because the dev server and hmr server are in separate plugins that don’t know about each other...

[benduran]

Thanks for getting back to me! The reasoning for allowing the same port is because many developers at my company use a local CLI utility that mimics our Single Sign-On auth procedure, which is super useful for validating that our apps are reading user identities properly. However, this utility acts as a proxy and only supports HTTPS. Since Parcel's WebSocket connection logic currently relies on sniffing the window.location.protocol and window.location.host for determining how to connect to its WS connection, this makes the WS client assume that our SSO proxy is also hosting the HMR server on a different port (which it isn't).

I could see there being two actual solutions for this:

1. Allow user-configurable WS protocol, host and port for the HMR server or
2. Allow the HMR server to share the same port as the static server, perhaps on a different URL path

This would allow us to successfully use Parcel out-of-the-box without needing to rely on browser-sync to make this work. Let me know your thoughts, thanks!

[devongovett]

Oh I see. Have you tried the --hmr-port and --hmr-port CLI options?

[benduran]

Great question. I have! After doing some more noodling around, let me revise what I think would work:

Since our local development proxies are providing their own HTTPS connections, they expect the connections they're making to our development servers to usually be over HTTP. However, since the HMR Parcel server uses window.location.protocol (as seen here), this can break the HMR server connection.

Would it be possible to allow for having the Static Bundle server listen over either HTTP or HTTPS, and allow the HMR server to listen over HTTP or HTTPS, where maybe the Static Bundle server is listening over HTTP and the HMR server is HTTPS and provides its own (or user generated) SSL certs? I think this would solve the problem.

Let me know if that isn't clear. Thanks!

[devongovett]

I see. So a separate —hmr-https option would work then?

[benduran]

Yep! I think that would be sufficient to provide a solution for this use case 👍

On Sun, Nov 17, 2019, 9:52 PM Devon Govett notifications@github.com wrote:

I see. So a separate —hmr-https option would work then?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/parcel-bundler/parcel/issues/2275?email_source=notifications&email_token=ABQYTH5LGBYI5E6MT66S7LDQUIUSBA5CNFSM4GDC4MFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEJIW6I#issuecomment-554863481, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQYTH7JWRFX4W7ZIF2CMBLQUIUSBANCNFSM4GDC4MFA .

[endafarrell]

+1 for a --hmr-https option - it would make my particular setup easier (nginx is infront, reverse proxying both an API and a parcel-bundled static site, but special locations for large media files coming from elsewhere) too. Right now I just reload the page rather than getting the value of the HMR.