all of this looks OK before #374 was introduced.
Timeout was introduced in #360 and update check was skipped entirely in production.
Now it's all back to naive and potentially breaking implementation.
The update check is happening behind a catch statement. It's not possible for it to crash the program.
Following is possible:
I consider this a bug, because I cannot prevent any of this.
At least consider a --no-update-check option
There is a timeout in place, so most of these 3 cannot happen (2).
print irrelevant warnings during startup, e.g. SSL failure
I don't think it's irrelevant. If the check is not working, we need to inform the user. No matter what problem caused it.
I also see a long hang on startup when starting serve on our network-restricted docker farm. To reproduce locally, I disabled outgoing connections to the registry and removed the cache:
# iptables -I OUTPUT -d registry.npmjs.org -j DROP
# rm -r /tmp/update-check
and serve hangs for over two minutes on startup - so the timeout is either too big, or not working correctly.
@leo, it is irrevant if you are not interested in any kind of update check. In production, for example.
All I ask for is the option to disable the update check. I am interested in serve feature, not update, especially in production environment.
Of course, update check is useful, I don't dispute that, especially during development, but in production deployments, all it does is useless and out of context.
I am also deploying to a network restricted environment and my app takes two minutes to start. I hope the merge request above will be accepted or some other option added.
In the meantime, what's the last version that either didn't have an update check or allowed it to be disabled?
@davemorrissey, in my case, I run it in docker, and I was able to short-circuit the whole process by following:
# dummy registry effectivelly disables update check and avoids irrelevant connection errors and startup delays
RUN echo "registry=http://localhost" > .npmrc
# /etc/hosts entry avoids DNS lookup delays and errors when resolving self hostname
CMD printf "127.0.0.1 $(hostname)" >> /etc/hosts && serve -l ${PORT:-80} -s
Most helpful comment
I also see a long hang on startup when starting
serveon our network-restricted docker farm. To reproduce locally, I disabled outgoing connections to the registry and removed the cache:and serve hangs for over two minutes on startup - so the timeout is either too big, or not working correctly.