If a package in node_modules needs to be compiled for older browsers,
simply symlink the package directory into your application somewhere, and
then import the package as you normally would.
Because of the symlink, code within the package will be compiled as if it
was part of your application, and any imports that refer to modules in the
package will automatically use the compiled code rather than the raw code
from node_modules.
Note that you can also symlink individual files to make them be compiled
like application modules, rather than linking an entire package directory.
Creating symlinks could be considered a form of configuration, but
otherwise this is a zero-configuration solution to selectively compiling
packages within node_modules, which has been something of a holy grail in
the JavaScript community lately.
https://github.com/meteor/meteor-feature-requests/issues/6
The bulk of this commit implements `builder.copyNodeModulesDirectory` to
allow more than one `node_modules` directory to be copied to the same
destination with as much safe symlinking as possible.
However, the crux of the fix for #9738 is the removal of the call to
`builder.generateFilename`, which deserves additional explanation.
If multiple directories are copied to the same output path by the builder,
in some cases it makes sense to ensure distinct directory names by adding
numeric suffixes to some of the directories.
In general, `builder.generateFilename` can get away with this renaming
only if the exact names of the directories are an implementation detail.
However, the code changed by this commit was altering the names of
`node_modules` directories whenever a package had both an `Npm.depends`
and a local `node_modules` directory.
Not only is it totally invalid to change the name of a `node_modules`
directory, but there is also no harm in copying the contents of multiple
`node_modules` directories into one final directory called `node_modules`.
Should fix#9738.
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.
