Fixes#9827.
The client.s.databaseName property appears to have been introduced a long
time ago (in 2014), so it seems reliable:
14fd60b99d
The use of client.s.options.dbName was only recently introduced in #9790,
since the MongoDB.connect callback now receives a MongoClient object
rather than a Db object. Not sure if client.s.options.dbName was ever
reliable, but at least we know when the problem started.
This functionality was originally intended to allow importing
compiled-to-JS modules from `node_modules`, by precompiling any modules
found in top-level npm packages, as long as a Meteor compiler plugin was
registered for the module's file extension.
As discussed in #9800, this extra compilation burden can be non-trivial,
especially if you happen to install an npm package such as `less`, which
contains hundreds of `.less` files in the `node_modules/less/test/`
directory.
More generally, this functionality was an early attempt to enable
selective compilation of `node_modules` directories, but it was not a good
solution to that problem, because in almost all cases the extra
compilation was unwanted.
Meteor 1.7 (formerly known as 1.6.2) will give full control over selective
compilation of `node_modules` back to the application developer (#9771),
which should afford a much better solution to this problem. If you've
installed some `.less` or `.scss` or `.ts` files from npm into your
`node_modules` directory, just create a symlink to the package directory
within your application, and those modules will be compiled and become
importable by other JS modules, as if they were part of the application.
Workaround for #8598: the Node Mongo driver has at least one bug that can lead
to query callbacks never getting called (even with an error) when leadership
failover occur.
Note that while we did fix one Node Mongo driver bug and close#8598, we've
heard reports that there are more similar issues, so this workaround seems like
a good plan.
If the max size is too large (at least on windows_x86), the process
silently exits without doing anything, which is arguably worse than just
using the default max space (i.e., not passing the option).
https://github.com/meteor/meteor-feature-requests/issues/283
The ProjectContext#_buildLocalPackages method calls
IsopackCache#buildLocalPackages which calls _ensurePackageLoaded for each
local package, so this commit exposes how long each of those
_ensurePackageLoaded calls takes (when METEOR_PROFILE is enabled).
* Update MongoDB driver to 3.0.5
* Use `MongoClient` instead of `Db` in Meteor Tool
* Update `mongo-livedata` test for new MongoDB driver version
* Consider `BulkWriteError` when checking MongoDB errors
Since jquery used to be a core package, and the most recent Meteor release
(1.6.1.1) imposed the ~1.11.11 constraint (note the ~), jquery@1.12.1
won't be usable with Meteor 1.6.x until it is republished after the next
Meteor release, which will no longer constrain the jquery version, because
jquery is no longer a core package (#9607).
In order to publish these two packages sooner rather than later, we need
to relax their jquery version constraints, because we don't want to
publish jquery@1.12.1 yet. The relaxed @1.11.11 constraints in these
package.js files will remain compatible with jquery@1.12.1, so this change
should be safe for the forseeable future.
Although there was a comment in this code about not applying .meteorignore
files to the contents of node_modules directories, I'm pretty sure that
was the wrong decision, because .meteorignore merely limits what Meteor
tries to compile as application code, and does not actually modify or hide
node_modules files from other parts of Meteor (or Node).
In other words, there's no harm in letting .meteorignore apply to
node_modules, and there may be a LOT of benefit, because it allows the
developer to fight back when compilation descends unexpectedly into an npm
package that contains non-.js[on] files for which a compiler plugin has
been registered, an obscure but not uncommon behavior originally intended
to allow importing CSS assets from npm packages:
* https://github.com/meteor/meteor/issues/6037
* 43659ff561
* a073280e3f
* https://github.com/meteor/meteor/issues/5242
* https://github.com/meteor/meteor/issues/6846
* https://github.com/meteor/meteor/issues/7406
However, we now have a much more powerful tool for selectively compiling
specific npm packages: #9771. In light of this new approach, we should
probably remove the promiscuous node_modules compilation behavior
altogether, as it might speed up rebuild times for many applications whose
developers don't know or care that this behavior exists. For example,
abandoning this behavior would prevent the problem reported here:
https://github.com/meteor/meteor/issues/6950
In the meantime, this commit makes .meteorignore work for node_modules.
Workaround for #8598: the Node Mongo driver has at least one bug that can lead
to query callbacks never getting called (even with an error) when leadership
failover occur.
Before this change,
meteor create --list
would produce output containing the following line:
todos-react: https://github.com/meteor/todos#react
but "meteor create --example todos-react" would create the blaze version of the todos example.
This was because for some reason the code is using a # to append the name of the branch, instead of /tree/.
