Note that the value of the "main" property must include the ".node"
extension explicitly, because I have yet to encounter an npm package with
a native "main" module that omits the ".node" extension, and I am loathe
to start calling files.stat(id + ".node") uselessly for every single
missing module.
Fixes#7947.
Meteor 1.4.2 has been mostly focused on improving rebuild times, but what
ultimately matters is the time from changing a file to being able to make
requests against the restarted server, and any code that runs before
server startup should be considered part of that critical path.
If you have a lot of packages, and they do non-trivial work on startup,
this commit should give you much better insight into where time is spent.
Credit to @stubailo for pushing me to provide Meteor developers with
better profiling tools, and thanks to @veered for this specific idea.
Note: because tools/tool-env/profile.js is now loaded as-is by boot.js,
certain ECMAScript features are off-limits, e.g. ...rest params.
This test has been the primary source of test suite unreliability in
recent weeks. By marking it "slow" I'm effectively disabling it on
CircleCI, which I think is acceptable because (1) it is, in fact, quite
slow; (2) it passes locally on Linux; and (3) it depends on the timing of
file change notifications, which is a recipe for test flakiness due to the
general non-determinism of file watching, but not necessarily a sign of a
broken developer experience.
Like other "slow" tests, I will keep running this test locally via
meteor self-test --slow 'javascript hot code push'
as part of the manual QA testing that we do.
It's a shame that Pathwatcher issues this warning using console.error,
without taking any verbosity options into account:
https://github.com/atom/node-pathwatcher/blob/7ef76e5dfd/src/main.coffee#L53
Fortunately, I believe I've identified the underlying reason why this
happens, which may help resolve the following issue:
https://github.com/atom/node-pathwatcher/issues/98
If all goes well, I'll submit an upstream pull request.
I've also reinstated an old file watching test that I mistakenly removed
when I attempted to switch to chokidar instead of pathwatcher.
This is a bit different from the previous strategy of invalidating
optimistic functions for specific npm package names.
Now, whenever we make changes to the contents of a specific node_modules
directory, or whenever the developer independently modifies an app's
node_modules directory, all optimistic results derived from paths
contained within that node_modules directory will be marked as dirty, and
thus may need to be recomputed.
This strategy prioritizes starting fewer watchers (just one per
node_modules directory) while still allowing npm packages to be added or
removed while the app is running:
https://github.com/meteor/meteor/pull/7668#issuecomment-255120373
The drawback is that changes within subdirectories of node_modules will
not be detected until the server is fully restarted, but that seems like
an acceptable tradeoff, since npm packages change much less often than
application code.
Version constraints are unnecessary when publishing a release, and tend to
complicate things when the constraints are out of date with packages that
are updated by the release.
When a download aborts prematurely, the status code is often 200 OK, even
though we probably should not proceed with any further processing of the
downloaded information.
This silent failure leads to problems like the dreaded "Error: ENOENT: no
such file or directory, open... os.json" (#7806 and others), which were
hard to diagnose properly because the failure occurred only later, when
extracting a buffer that downloaded incompletely.
The getUrlWithResuming helper should be able to retry after this error is
thrown, which will result in a more helpful warning, even if in the most
common case, i.e. MaxCDN failure, it will never actually succeed.
Note that this change will not help until Meteor 1.4.2 is officially
released and becomes the implementation used to download later releases.
Mitigates #7806.
This will make it easier to use tools like https://yarnpkg.com/ with the
right version of Node, etc.
With this commit, here's all you have to do:
meteor npm install -g yarnpkg
Then test that it works:
meteor yarn info
Note that any commands registered by Meteor itself will not be honored.
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.
* 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
We try to kill any mongod processes before starting new ones, but this
change kills it when the development server shuts down, too.
Killing mongo on shutdown is particularly important for tests that run
meteor multiple times in a row, and for whatever reason fail to find and
kill running mongod processes on startup, e.g. because the --port has
changed (#7563).
This comment by @glasser seems to suggest this is a reasonable idea:
https://github.com/meteor/meteor/issues/2182#issuecomment-45685614Fixes#2182 and possibly other related bugs.
Most notably, this update provides error stack traces that include context
from Promise.await calls and await expressions, so (for example) you can
tell where a certain yielding files.* method was originally called,
instead of only getting a useless native stack trace.
