(This is the third attempt to enable this. I believe as of
permessage-deflate 0.1.3, it works properly.)
By default, we attempt to use this for every websocket message on both
client and server.
On the server, we provide the SERVER_WEBSOCKET_COMPRESSION environment
variable to control compression. If $SERVER_WEBSOCKET_COMPRESSION is
set, then it must be valid JSON. If it represents a falsey value, then
we do not use permessage-deflate at all; otherwise, the JSON value is
used as an argument to deflate's configure method; see
https://github.com/faye/permessage-deflate-node/blob/master/README.md
We do not provide a way to use it only on some messages. The underlying
spec allows this but permessage-deflate does not; see
https://github.com/faye/permessage-deflate-node/issues/2
We do not provide a mechanism to control compression parameters on the
client side. The assumption is that the common reason to care about
compression parameters is to control server per-connection memory
usage. (The noContextTakeover configuration parameter should save some
memory and still allow for some compression, for example.)
Addresses #3007 (which will not be fixed until this change is deployed
on the package server as well).
`meteor run` doesn't always write changes to `.meteor/versions`: it only
does so if its release (or checkout-ness) matches `.meteor/release`. So
it preferred to just remember the value of `.meteor/versions` from
rebuild to rebuild rather than forgetting what it knew and re-reading
the possibly-not-updated file.
However, if some other process changes `.meteor/versions`, it would
ignore that change. With this fix, if `.meteor/versions` changes then
that is considered to be the previous versions list, not the last
version list from the same process. For example, this would commonly
happen due to using `meteor update` to update packages (without changing
the tool, which would cause the runner to stop).
Fixes#3582.
This restriction was originally in place because we did not know of a
use case for bare files on the server. The main use case for bare files
is putting pre-existing files in your app which expect top-level `var`s
to be "exported", which is common in browsers but not in Node.
However, there is a use case for this on the server: putting
pre-existing files that were originally written with clients in mind but
which function fine on the server into your server code. So we'll relax
the restriction.
Fixes#3681.
Adding the same file twice in the same package is now an
error. Previously, this could either lead to the file being included
multiple times (eg, JS), or to a build time crash (eg, client-side
assets).
Velocity has visited the mirror sometimes before
it is ready. With this new check that is already
used in the testing frameworks this no longer
happens.
This commit also handles the upcoming breaking
change regarding the rootUrl of the mirror.
See: https://github.com/meteor-velocity/velocity/issues/260
It used to create a directory with an underscore instead of a colon
Now, it just removes the prefix.
In cases where the name of the package has more than one colon or starts or ends
witha colon, we report an error.
With this change, `meteor update` with no arguments, in addition to
updating direct dependencies, updates patch versions of indirect
dependencies, so you will get your version 1.4.2 in the above example.
Background: As of the new solver, we already prefer patched versions
when selecting a version for a new indirect dependency. For example,
if 1.4.0 is the oldest version we could choose, we will take 1.4.1
instead if available. However, if 1.4.2 came out, there would never
be an occasion to take it, unless you explicitly typed
`meteor update the-indirect-dependency`. `meteor update` with no
args expands to `meteor update <all direct deps>`.
Also improve comments, tests, and code around CS.Input.
Tracker.flush() will still guarantee that all computations and
afterFlush callbacks have been fully flushed, but the implicit flush
cycle started by an invalidation or afterFlush call will yield to the
event loop for 10ms every thousand computations.
Fixes#3901.
Reviewed at https://rbcommons.com/s/meteor/r/25/
