HMR when Snowpack is used as middleware

[aral]

1. My server is running on https://localhost:443
2. It starts up the Snowpack server at https://localhost:444
3. It integrates Snowpack via a Connect/Express-style middleware that calls loadUrl() on the Snowpack server and, if the result is 404, calls next() to let the main server’s routes handle the call.

When I integrate Snowpack as above, the HMR websocket connection fails as it tries to access (wss://localhost) as Snowpack’s HMR engine has no knowledge of my custom server and cannot handle upgrade events on it.

Could we expose hmrEngine from the dev server and/or otherwise allow me to provide a reference to my custom server so that the HMR engine can use that instead of the Snowpack server to respond to upgrade events?

Update: And if I specify a separate hmrPort, I’m getting an SSL protocol error.

Update 2: See this comment by @Xiot for a summary of the two issues that underlie the behaviour I was seeing as well as a workaround.

[aral]

(Note: I updated the issue description after looking into this a bit more.)

[Xiot]

I was able to get this to work simply by setting the hmrPort to something else (ex 445). This caused snowpack to spin up another port just for HMR, and it seemed to work just fine.

[Xiot]

That looks good.
I can dig through the code, but how is the HmrEngine handle the upgrade request if the server isn't passed in?
Since the ws isn't exposed, there doesn't seem to be a way to call handleUpgrade on the WebSocket.Server instance.

[FredKSchott]

You're right, don't that's supported at the moment. Curious how we could support that: would we need to pass in entirely different cert info for HMR, different from the server?

[Xiot]

Two ways that I can think of.

1. Allow the user to pass a server object to use as the hmr server.
2. Build up a new server (http / https depending on the secure property), and use that. We could use the same snowpack.[key|crt] file as the main server.

[aral]

Either of those ways would work for the given use case.

However, given that we now have running the HMR server on the same port as the Snowpack server working, I’m not sure what the use case is for having the HMR server on a different port. What was the original use case for this?

For my use case, I run my server on port 443 and I run the Snowpack server at 444.

Currently, my only blocker on this is that Snowpack needs the certificate and key files in the current directory and there’s no way to specify them otherwise (I keep them in a settings directory; this isn’t specific to HMR but to Snowpack in general so I’m going to open a separate discussion for that). Once that’s sorted, I don’t personally see when I’d need HMR running on a different port to the Snowpack server.

Update: opened the separate discussion I mentioned above.

[Xiot]

I created a PR #2314 that went with approach 2, but I had the same thought about the separate HMR port.