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.
This used to "work" (somewhat accidentally) before we got stricter about
which `node_modules` directories `Npm.require` can search:
971d2b1272
This commit should fix the problem with `juliancwirko:postcss` reported
here: https://github.com/meteor/meteor/issues/9094#issuecomment-331964596
Note that this only works for `Npm.require` when called during the build
process, not at application runtime. Use ordinary `require` for that.
Calling unwatchFile may result in stopping the watcher before watchFile is
called, which then restarts it. This temporary stoppage appears to cause
change events to be missed sometimes. In particular, preventing this
stop/start with the acrobatics in this commit seems to fix recent
compiler-plugins.js test failures.
* When awaiting Mongo, wait until the heartbeat has pulsed after election.
> Prologue: A heartbeat is used amongst members of a MongoDB replica set
to poll the status of said members.
When we are initiating a new replicaset for the test Mongo server, the
replicaset is not fully prepared to accept writes until the voting
members have negotiated and propagated their decision about who is the
"primary" to all members involved. This seems to be delayed by almost
_exactly_ the default heartbeat interval, which is 2000ms.
The heartbeat interval is marked as an "internal only" property in Mongo
so I was hesitant to lower it. It's also a new property in Mongo 3.2
which might explain why this cropped up a while ago.
I believe this heartbeat delay is the only explanation for why the
`rs.status()` (i.e. `replSetGetStatus`) believes it is ready before the
`mongod` has actually printed "transition to primary complete" to the
log.
Fixesmeteor/meteor#9026.
* Replace addl. variable occurrence with the new `firstMemberState` var.
This is another way of addressing the problem I attempted to fix with
f34c5ec926 earlier today.
Apparently, older versions of compiler plugin-registering packages such as
standard-minifier-css and templating-compiler still depend on older
versions of the meteor package, which may still use path.join to import
fibers/future. This can be fixed by republishing those packages, as I did
in 917b01ac5f, but I'd prefer not to
republish every compiler plugin package.
Fortunately, we can also solve the problem by being more tolerant in the
implementation of Npm.require, which is what this commit does.
Ever since Meteor 1.3 first introduced a module system based on something
other than `Npm.require`, we've continued throwing missing module
exceptions that refer to `Npm.depends` and/or `Npm.require`, even if the
developer called `require` or used an `import` declaration. This commit
fixes that, so that all missing module exceptions look like 'Cannot find
module "module/name"'.
I also noticed recently that `Npm.require` is capable of returning modules
installed in `node_modules` directories completely outside the app, which
is bad news for development/production reproducibility. Fixed that too.
CC @hwillson who has spoken of deprecating `Npm.require` entirely, and
just using `require` everywhere, instead.
This is performance-sensitive code, and I think this extra (uncached) call
to files.statOrNull could be contributing to test timeouts on Circle CI.
Follow-up to #9030.
As outlined in #3854, if `meteor --settings` points to a
directory instead of a file, an application gets caught up
in an infinite rebuild loop. Since it was assumed only a
file would be configured via `--settings`, a file watcher
is created for the specified directory, and that watcher
is then triggered ad infinitum.
These changes prevent a file watcher from being created
on a `--settings` directory.
