The jscript transform is perfectly safe for server code, and relatively
cheap compared to the cost of having to compile every file for both the
client and the server, just because the set of plugins is different.
Setting mongoOptions.server.auto_reconnect was removed by #7880 via commit
0ffb9ac824, though it seems the Server
options still respect autoReconnect, even in version 2.2 of the driver:
http://mongodb.github.io/node-mongodb-native/2.2/api/Server.html
That said, having inspected the code of the `mongodb` package, I do not
believe this change is really critical, since the default value for
autoReconnect appears to be true.
More importantly, I can't find any support in the code of the `mongodb`
npm package or its dependencies for the claim that setting
mongoOptions.server.reconnectTries to 0 is the same as making it infinite,
so this commit sets it to Infinity.
Because I previously published a 1.2.3 version with the same code as
1.3.0, I have also published a 1.2.4 with the same code as 1.3.1, though
of course you should use the latest version (1.3.1) if possible.
* Reconnect to mongo indefinitely.
A fix for https://github.com/meteor/meteor/issues/7822
It seems the driver now always autoReconnects, but only for 30s.
To get the old (sensible) behavior of endlessly reconnecting, we set `reconnectTries` to 0.
* Releasing an rc of mongo package
This involved rolling some package versions back to non-beta versions,
since release-1.4.2 was previously merged into devel, but I think the
result is a more reasonable state for the devel branch.
The previous implementation had a run time quadratic in the number of CSS files with an associated source map. This new implementation has a linear run time because it iterates only once through all mappings of each CSS file.
I had to scrap the 1.4.2-beta.8 release because meteor-tool@1.4.2-beta.8
got published by a partial run of the publish-release script, but then the
publish-release script thought meteor-tool changed after that, and I
didn't want to republish it as something like 1.4.2-1-beta.8.
This tweak is intended to fix the following publish-release error:
=> Errors while publishing:
While publishing package tracker:
error: Longform package description is too long. Meteor uses the section of the Markdown documentation file between the first and second headings. That section must be less than 1500 characters long.
After much debugging, I have tracked down and fixed the root cause of the
test failures: colorized app output was silenced because the Log.format
function could not require("cli-color").
Revert "Wait for "=> App running at:" in packages/test-in-console/run.sh."
This reverts commit 0713b9d153.
Revert "Use console.log to print test-in-console listening message."
This reverts commit a421da5a5e.
This test case currently fails because the `cli-color` npm package cannot
be required, which means all colorized logging messages printed by the app
will throw in the eachline callback(s) in AppProcess#start, which breaks
virtually any test that waits for an app to print a ready message.
For some unknown reason, the "test-in-console listening" message is not
being printed to STDOUT when this script runs on Travis CI any more. We
should investigate why that is, but it's important to get these tests
running (and passing) again.
* Update CoffeeScript to 1.11.0, which supports modules; update check for whether to pass CoffeeScript’s output to Babel to look not just for backticks, but also for `import`, `export` and `function*`, the current ESNext features output by CoffeeScript
* Add tests for imported modules using CoffeeScript’s new native import statement
* Test that CoffeeScript native export statements work, by importing something exported by such a statement
* Improve regex
* Optimize regex