The accounts system `logoutOtherClients` method is using
a connection close delay to make sure clients have a chance
to get updated tokens, before older tokens are removed.
Certain tests are setting this delay to 0, to help speed
things up. The Meteor Mongo 3.6 changes have brought back in
the need to use Mongo journaling, since the ability to disable
journaling has been deprecated by Mongo. This means there is
now a slight performance hit on certain Mongo operations,
due to the increased time needed to cover the write to disk.
This slight performance hit is causing the tests that use the
0 connection close delay to fail, since they are not waiting
long enough for clients to get updated tokens, before they're
removed. These changes increase the test connection close
delay, to fix the failing tests.
* Removed fiber wrapper around OAuth middleware.
With commit 3b18863, connect handlers are guaranteed to run in a fiber, making the fiber wrapper in the OAuth middleware superfluous. Additionally, because it manually wraps the middleware in a Fiber directly, it is losing access to the properties stored in the existing fiber (meteor/meteor-feature-requests#156).
* Bump oauth Meteor package version to 1.2.2.
This reverts commit 573f14f171.
As discussed with @glasser, this change may have been more disruptive than
helpful (e.g. #9730) and could also have negative performance
consequences. Since we don't actually rely on `withValue` awaiting the
result of the callback (yet), it seems safest to revert this change, and
possibly add a different method called something like `withAwaitedValue`
at some later time, if necessary.
Fixes#9730.
I've reverted match properties that return class instances back to normal functions, so that they can be called as constructors.
Also, I added tests to make sure we catch this issue if someone else gets the same idea that I had!
This should shave down bundle sizes by 14.4 kb for many non-blaze projects.
The other core meteor packages have not depended on `underscore` since #9362. However, we are only able to remove this last dependency now due to the previous commit, which eliminated usages of `underscore` from apps that did not have the package listed in their `packages` files. This was causing CI test failures that now should be corrected.
Any meteor apps currently using `_` without `underscore` listed in their `packages` file will need to add the package explicitly.
Version number of `meteor-base` bumped from 1.3.0 to 1.4.0.
There are only a few uses of `underscore` in these apps, and two of them actually used `underscore` without having it explicitly listed in their `packages` file.
This is a problem, because the apps were relying on the dependency from `meteor-base`, which we want to remove to cut down bundle sizes.
For the `modules` test app, I've added `underscore` to the `packages` file, because it is using `_` in an assertion about the module system. For the other app and all other uses of `_`, rather than add `underscore` to the `packages` files, I took the modernization route and replaced the functions with their ES6 equivalents, and then removed `underscore` from all `packages` files.
In order for Meteor to maintain its commitment to being a
zero-configuration tool, any configuration options that we add must come
pre-configured in the best way possible for newly created apps.
In particular, the default new Meteor app must contain a reasonable
testing story, or else we are signalling to the community that testing is
an afterthought.
With that said, this PR is still a work in progress. I welcome your
feedback on how best to configure the default `meteor create` starter app.
Builds on #9690 and #9714.
Setting meteor.testModule is a great way to specify test entry points
explicitly, rather than relying on Meteor's isTestFilePath heuristics:
https://github.com/meteor/meteor/blob/devel/tools/isobuild/test-files.js
The syntax is identical to meteor.mainModule, so you can set an explicit
meteor.testModule.{client,server,...} for each platform. If a testModule
is not specified for a platform, then Meteor's existing rules about test
file paths apply for that platform, as before.
If a testModule is specified, that module will always be loaded eagerly
when running `meteor test`, in addition to any other modules that load
eagerly because of meteor.mainModule or other rules regarding module
loading. If you run `meteor test` without the `--full-app` option, then no
application JS modules other than the testModule (and any modules imported
by it) will be loaded eagerly.
If meteor.mainModule.{client,server,...} === false, no modules will be
loaded eagerly for that architecture. This is useful if you have an app
with no special app/{client,server} directory structure and you want to
specify an entry point for just the client (or just the server), without
accidentally loading everything on the other architecture.
