In the past, `api.addFiles('foo.gif')` would make foo.gif an asset if
there was no extension handler for gif active. In fact, it would make
it a dual client/server asset even if that was unintentional.
This led to a few problems:
(a) People often left out 'client' and ended up packaging an unnecessary
second server copy of the asset
(b) The implementation meant that `api.addFiles('foo.css')` would actually
add foo.css as a static asset on the server (this was already fixed
on batch-plugins via explicitly looking for wrong-arch
classifications)
(c) Now that we have linters, if a file is used by a linter but not by a
compiler (eg linter config files), there was no way to say in a
package "add this file, but just for linters, don't make it a static
asset too".
These are only really issues in packages, not apps. In apps, we avoid
them by only marking things as static assets if they are in public or
private (and not letting those things be considered as other kinds of
sources).
This is a backwards-incompatible change, but it does not affect apps or
published packages, just packages built from source.
Before this change, number of catch-up attempts was N*M, where N is number of
writes inside of the fence, and M is number of active observers on affected collections.
Every catch up issues yet another query to find the latest oplog entry.
It was extremely inefficient, in terms of both CPU usage and added latency.
After executing write-heavy methods, application process was occupied for many seconds
doing the same thing over and over again.
This change provides a performance improvement for all kinds of workloads.
Closes#550.
`loginWithPassword` now matches username or email in a case insensitive manner.
If there are multiple users with a username or email only differing in case, a
case sensitive match is required.
Although `createUser` won't let you create users with ambiguous usernames or
emails, this could happen with existing databases or if you modify the users
collection directly.
Because MongoDB does not support case insensitive indexes, we perform a case
insensitive query both before and after inserting a new user, removing the user
when we detect another matching user has been inserted in the meantime. This
leaves us with the theoretical possibility that a server crash could occur in
between the insert and the second query or remove. In that situation there
would be two accounts with a username or email only differing in case, so we
will require a case sensitive login.
Also, detect if mongod fails due to bad locale and print a better
message. I think that with these default values, mongod shouldn't fail
any more (unless you've actively set locale env vars to unknown locales)
but if it does, we want a better message, which will link to #4019.
Fixes#4019.
The original index, "emails.validationTokens.token" is never used in any meteor packages. A search of "validationTokens" across all the packages in `meteor/packages` returns nothing.
The correct index should be, "services.email.verificationTokens.token". This is used in the `verifyEmail` method to locate the correct user record. Without a matching index, this causes a full table scan each time `verifyEmail` is called.
Fixes#4482.
Previously we were carefully cloning the relevant pieces of most
modifier $ops but not for replacement (or for $pushAll, for that
matter). Instead, just clone the full mod doc always.
(The purpose of cloning here is so that mutable state isn't shared
between the arguments to minimongo APIs and internal LocalCollection
data structures.)
Fixes#4377.
`Spiderable.requestTimeout` can now be changed in server code in an app
to the number of milliseconds to wait until spiderable gives up on
phantomjs.
This is motivated by frontpage hitting 15 seconds at times (due to some
other problem we have), but regardless slow page loads are better than
non-crawlable ones.
The #1 goal is to not say, "Your packages are at
their latest compatible versions" whenever an
update has no effect. That isn't necessarily
true. `meteor update` with no arguments never
updates a major/minor of an indirect dependency,
for example. Also, you may have specified some
packages on the command line (though arguably
"your packages" could be interpreted to refer to
those packages).
In addition, `meteor update` with no arguments now
reports any direct or indirect dependencies that
aren't at their latest versions.
For example:
```
Your top-level dependencies are at their latest compatible versions.
Newer versions of the following indirect dependencies are available:
* aldeed:collection2 0.1.7 - 2.3.3 is available
To update one or more of these packages, pass their names to `meteor update`.
```
Sort of related to #4170.
(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.
