using a known hostname but dynamic port

[BrianHicks]

using a known hostname but dynamic port

[BrianHicks]

hmm, actually, I did a little more searching and I think in the long term we may just want to use the server! But the short-term point still stands.

[lydell]

Hi! The idea was to use the ELM_WATCH_WEBSOCKET_URL environment variable when you need something dynamic. Have you tried that?

[lydell]

#87 (comment) would allow this to be dynamic as well.

[BrianHicks]

Doesn't ELM_WATCH_WEBSOCKET_URL set the same field? How would it make the port dynamic?

[lydell]

Then I must have failed again understanding exactly what you meant 😅

[BrianHicks]

ah, ok. Let me add more details then:

• I have to develop this app through a proxy to make a couple things work right. I'm not up on all the details exactly, but basically app.mycorp-dev.com is my "local" URL.
• I run something on my computer that overrides that URL, but only for :80 and some other special ports
• I can get elm-watch working if I set the host to to localhost. Then I don't have to mess with the proxy.
• At that point, I care a lot about the hostname, but I don't care at all about the port, until…
• When I make a change, sometimes there is a port conflict and then the whole process supervision scheme crashes and I have to restart it

If I could set a fixed host but a dynamic port, that'd be fine! I don't really care what the port is, just the host.

I admit this is a very specific set of requirements, though. 😆

[lydell]

Hmm, so is this correct?

1. Your dev site is on app.mycorp-dev.com
2. By default elm-watch connects to the same hostname, but you want it to connect to localhost
3. You can configure the hostname via webSocketUrl, but then you also have to set the port
4. By default elm-watch gets a free port from the OS, but you have to set the port to a known value so that you can use webSocketUrl, but that sometimes results in a port conflict
5. So you want to be able to use the hostname but not the port, because you think that would avoid the port conflict?

If so, I’m not sure that would help. When elm-watch gets a free port from the OS, it saves that port in elm-stuff/elm-watch/stuff.json, so it can connect to the same port next time. So I’m thinking you’d get port conflicts anyway?

But with #87 (comment) you’d be able to set a new, free port every time. However, then you end up with old compiled JS trying to connect to the old port, which isn’t ideal. (That’s why elm-watch saves the port it got.)

[BrianHicks]

Yeah, you've got it. And that makes sense. Hmm. Well, I think this isn't a forever issue; I'm eventually going to have to rework how the processes are spawned and at that point we'll have a better chance to clean up.

I'm going to close this for now since given what you've said the requested change would not fix the problem!