-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
using a known hostname but dynamic port #88
Comments
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. |
Hi! The idea was to use the |
#87 (comment) would allow this to be dynamic as well. |
Doesn't |
Then I must have failed again understanding exactly what you meant 😅 |
ah, ok. Let me add more details then:
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. 😆 |
Hmm, so is this correct?
If so, I’m not sure that would help. When elm-watch gets a free port from the OS, it saves that port in 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.) |
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! |
At work, we have to develop the frontend through a proxy. That makes
webSocketUrl
an absolute necessity, so we're using the beta version ofelm-watch
. However, sometimes the process manager tries to start a newelm-watch
instance before the old one has exited, so we get port conflicts and the app fails to start. This isn't the hugest problem—we can just restart the watcher—but it makes me wonder if it'd make sense to specify the components of the URL separately. For example, instead of:I wonder if we could do:
Or even use the pseudo-syntax that you show in the examples!
Longer-term, I hope to get rid of the process manager that's exhibiting this iffy behavior, but this would help sand down a rough edge in the mean time!
The text was updated successfully, but these errors were encountered: