Something went wrong with 1.5-rc.2 such that publishing meteor-tool failed
with the following error on all platforms:
While publishing package build for meteor-tool:
error: Cannot override existing build
This makes no sense to me, but it necessitates another RC release. To be
clear, meteor-tool@1.5.0-rc.2 has not been successfully published on any
platform, so please don't bother trying to update to it.
Now that dynamic modules are part of the manifest that determines which
files are served over HTTP, I'm a bit paranoid about them somehow ending
up as <script> tags in the initial HTML of the application.
This commit adds another safety measure to prevent that, just in case the
boilerplate-generator package for some reason fails to skip items whose
.path starts with "dynamic/" (see my previous commit).
Because as @hwillson rightfully points out:
> that's what we're really exposing and `connect` themselves refer to the container that holds the defined middleware (the result of calling the `connect()` function) as a connect "app"."
As per the comment on line 653, this appears to be the best (only?) way to let users do things like set up a custom error page to catch app-rendering-time exceptions.
Previously we used the Node default behavior of just closing the
socket. This made it difficult for load balancers to understand if the
backend is buggy or the client request was bad (if Node is validating
something more strictly than the load balancer).
This only takes effect on Node 6; in older versions the socket is
already destroyed before the event is invoked. See
https://github.com/nodejs/node/pull/4557/ for details.
I had to scrap the 1.4.2-beta.8 release because meteor-tool@1.4.2-beta.8
got published by a partial run of the publish-release script, but then the
publish-release script thought meteor-tool changed after that, and I
didn't want to republish it as something like 1.4.2-1-beta.8.
