Previously, certain errors on the client/proxy socket would result in
the proxy keeping the websocket to the server open forever rather than
closing it. For example, disconnecting the client from the internet
without a graceful shutdown. This could easily be reproduced with any
app using `facts`, eg https://github.com/tarangp/test-observers.
Run the app, connect locally with one browser, connect from a second
computer, observe sessions going to 2, disconnect the second computer.
With this commit, sessions will go back to 1 in about a minute. Without
it, it never will.
This particular fix is not very compelling, since it uses undocumented
features of the stream interface. I will file an issue with the
node-http-proxy project tonight asking how we're supposed to do this.
This addresses #1769. I'll close that once we have a more compelling
fix, and once the similar bug is fixed in the proxies used in the
`meteor deploy` server and in Galaxy.
Could cause mongo startup to hang.
Reproduction:
$ meteor
=> Meteor server running on: http://localhost:3000/
# ... wait for server to start, ctrl-c.
# leaves '3002' in .meteor/local/db/METEOR-PORT
$ meteor -p 5000
# ctrl-c in about a second: once we've wiped the old local db
# but before we've configured the new one.
# before this commit, '3002' is still in the METEOR-PORT file.
$ meteor
# before this commit, hangs with:
Initializing mongo database... this may take a moment.
Could cause mongo startup to hang.
Reproduction:
$ meteor
=> Meteor server running on: http://localhost:3000/
# ... wait for server to start, ctrl-c.
# leaves '3002' in .meteor/local/db/METEOR-PORT
$ meteor -p 5000
# ctrl-c in about a second: once we've wiped the old local db
# but before we've configured the new one.
# before this commit, '3002' is still in the METEOR-PORT file.
$ meteor
# before this commit, hangs with:
Initializing mongo database... this may take a moment.
If an indirect dependency resolves to something other than a semver (or
a GitHub tarball), it will be stored in the 'resolved'. Our shrinkwrap
minifier (which helps to reduce spurious shrinkwrap file changes) needs
to recognize that.
Also, consistently use the "version" field in the minified shrinkwrap
file (which a comment already claimed we could do).
Fixes#1684.
We should never use the existence of a directory in our source tree to
make a decision, because git doesn't track directory existence, and it's
easy to end up with extraneous directories (containing gitignored files,
eg). So we should ignore programs/foo directories in apps if they don't
contain package.js.
"templating - template arg" fails before and after this merge
Conflicts:
packages/handlebars/.npm/package/npm-shrinkwrap.json
packages/handlebars/package.js
(semi-updating handlebars to shrink package size, vs deleting)
packages/minifiers/package.js
(two different new tests)
packages/minimongo/minimongo.js
(observe moved to a new file)
This uses less space on disk and starts up faster. It might mean
people hit the end of the oplog if the server gets really slow.
But, hey, then we can debug and test more oplog error modes.
Note: this is pretty slow. Before merging this branch, should cache the fact
that replset has been initiated on port N so that on the next run, if the port
hasn't changed, we don't need to re-initiate.
These directories are often left around when switching from another
branch; git does not delete the gitignored .build directory (but it will
show up annoyingly in 'git status').
The dev bundle contains a copy of the handlebars NPM module solely for
creating app.html. This is separate from the NPM module used by the
handlebars NPM package.
On the shark branch, we no longer use the handlebars NPM module for
Meteor template (it is being replaced by Spacebars), so in preparation
for that, we'll remove this barely-used build-time dependency on
handlebars.
A subsequent commit will remove it from the dev bundle.
Once the Spacebars API has fully settled (eg, it has been merged to
devel), we should get rid of this ad hoc templating and replace it with
Spacebars, either in webapp_server (driven entirely by program.json) or
by using unipackage.load in bundler.
This was a regression in 0.6.6 when we upgraded to a new unreleased
version of http-proxy which now requires an explicit option to set them.
See #1624.
