This dev bundle version bump is just to make sure nothing significant has
changed about transitive node_modules dependencies since last time, before
we bump the Node version for the 1.5.4.1 release.
In a previous commit, I changed
doc = _.extend({}, doc);
to avoid using underscore, thus:
doc = { ...doc };
While this may seem harmless, it broke a few Mongo.Collection tests
because _.extend copies *all* properties, both own and inherited, whereas
object ...spread only copies own properties.
However, the correct way to fix this problem is *not* to revert to the old
behavior, since flattening the inherited properties of a document was
never actually what we wanted. The old behavior was subtly broken, too.
Instead, we need to create a new object with the same prototoype as the
provided document, then shallow-copy the own properties. Any properties or
methods inherited from the original prototype will then be available on
the new object, even though they didn't get copied over.
I've intentionally left some trivial formatting changes in this commit to
remind myself which broken tests were fixed by this change.
AppVeyor does provide us quite a bit of value at no cost since we're
open-source software, but with only a single container at our disposal
under that plan, our build queue is often maxed-out for hours.
Since most Meteor developers are using 64-bit platforms, the 64-bit
tests provide the most value. Meteor doesn't have much (if any?) in the
way of 32-bit/64-bit exceptions so any functionality difference would be
at the OS level. Some day, we might bring this back.
This puts Meteor back on the official release track of Node.js 4, rather
than using its own custom build (from https://github.com/meteor/node/),
which had previously been necessary to add the garbage collection fixes
gained with
751f1ac08e
and
71f9cdf241,
both of which are now officially included in Node.js 4.x as of 4.8.6.
🎉
Even with $ErrorActionPreference, PowerShell won't automatically fail
when an external command fails with an error code. This explicitly
checks those exit codes and throws an error when that occurs.
Hopefully prevents false successes like that shown in this AppVeyor
test run: https://goo.gl/xxRsF9.
Though it was thought to be reliable when running through 'self-test' on
Windows, it's yet to be seen how reliable.
The worst thing that could come of adding Windows testing would be that
we have test failures again after such a string of green checkmarks and
confidence.
Also, reordered.
These take precedence over the UI, and I'm not sure the UI is taking
effect at the moment.
We don't need to build branches which start with 'dev-bundle-' since
those dev bundles won't be built yet when the tests are kicked off.
This implements a first generation of Windows CI testing. Presently,
this only runs valuable, hand-picked tests which have been known to work
in the past, and whose failure would indicate a critical problem.
A test which isn't passing doesn't mean that the feature being tested is
not working. For example, the 'create' test fails ostentatiously,
though the 'meteor create' command certainly works in practice. This
points to problems some compatibility problems with the 'self-test'
harness itself, some of which I'm aware of. Though, it likely will
highlight some legitimate problems which Windows users experience too.
There are a number of additional tests which should be enabled which
likely pass already, and many more which are failing and we should fix.
Additional tests can be added to the scripts/windows/appveyor/test.ps1
file as they've been deemed working.
Altogether, this will take extensive work to achieve the same level of
coverage our Unix test suite enjoy, but we've got to start somewhere!
cc @benjamn
This was dangerous because source is often a path relative to the old
target file, whereas files.stat was interpreting source as a path relative
to process.cwd().
Fixes#9203.
A while back, for performance reasons, we disabled yielding for all
files.* operations unless METEOR_DISABLE_FS_FIBERS was set to false.
This was safe for almost all files.* operations, because most of them have
a synchronous fs.*Sync version available.
For a more complicated operation like files.rm_recursive, however, there
is no synchronous or asynchronous counterpart in the fs.* namespace, so
the safety of disabling fibers is not guaranteed.
Lately, files.rm_recursive has become a major source of uncaught ENOTEMPTY
errors on Windows, because rimraf.sync fails with that error, and we don't
give files.rm_recursive_async a chance to delete the directory in a more
persistent, forgiving manner.
The only reason we haven't been falling back to files.rm_recursive_async
is that YIELD_ALLOWED is false by default, so canYield() returns false.
This commit distinguishes between canYield() and mayYield(), and uses
canYield() in files.rm_recursive to determine whether it is technically
safe to yield, regardless of YIELD_ALLOWED.
Anyone who ever asked "Can I go to the bathroom?" in elementary school,
only to be mercilessly rebuked with "I don't know, CAN YOU?" should
understand the difference between these two functions.
These errors are especially harmful because they cause files.rename to
fall back to copying rather than atomically renaming, which is both much
slower and not even remotely atomic.
This reverts commit b9f0a54b39.
Though probably a good idea for the future, this change was not really
necessary for Meteor 1.6, and probably too risky for a release candidate.
The `installPath` property was always essentially an absolute module
identifier that was simply missing the leading '/' character, so this
commit acknowledges that role by renaming the property to `absModuleId`
and adding the leading slash.
Previously, if more than one module in a package tried and failed to
import the same identifier, we would record information about only the
last failed import.
This was good enough for later attempting to resolve the failed import in
other packges or the application's `node_modules` directory (a concept
known as "peer dependencies"), but it sometimes discarded information
about whether the failed imports were dynamic. In particular, if the last
recorded failed import was a dynamic import, it could accidentally render
the entire peer dependency tree dynamic.
Although it's a bit more complicated than what we did before, I believe
the simplest solution is for the ImportScanner to maintain a mapping from
failed identifiers to lists of import information objects, rather than a
single object, so that no information is lost.
