The options.statOrNull function is not included in the JSON.stringify key,
but it affects the results because the implementation provided by the
ImportScanner relies on scanner._getFile to return fakeFileStat for
make-believe files created by the ImportScanner.
This becomes a problem if PackageSourceBatch#getResolver accidentally uses
a Resolver created initially for the ImportScanner, or vice-versa.
In particular, when a compiler plugin calls addJavaScript with a path
different from the original file path, the ImportScanner generates two
different modules, one of which imports the other. Only one of the files
exists on disk, though, so a special implementation of statOrNull is
necessary to keep the Resolver from having to share implementation details
with the ImportScanner.
When this system fails, users of compiler plugins see errors like this:
https://github.com/meteor/meteor/pull/7668#issuecomment-251976739
It's difficult to keep track of all the factors that could affect the
output of files.realpath, so it doesn't seem feasible to replace this call
with an optimistic function.
Fortunately, it's fine if the paths returned by IsopackCache#getSourceRoot
contain symlinks, and possibly even preferable, since
~/.meteor/packages/<name>/<version>
is more consistent than
~/.meteor/packages/<name>/.<version>.<junk>++<more junk>
though the latter happens to be a symlink to the latter.
Two mistakes: we were maintaining two redundant caches for
findAssignedGlobals, and callings tryToParse before checking globalsCache,
when often globalsCache already had a stored result.
This speeds up both getPrelinkedOutput (because we don't spend any time
generating the identity source map) and toStringWithSourceMap (because we
don't have to combine those source maps).
We still generate line number comments for files without source maps, so
it's relatively easy to find the source line for a stack trace.
An example of an npm package that triggers this bug is the `cli-color`
package, which has a package.json file with a "main" property whose value
is "lib", and a "lib" directory that contains an index.js file.
This is critical because it means Resolver objects can now survive
development server restarts, which means the optimistic Resolver#resolve
method can remember results indefinitely. Thanks to this change, the
Resolver#resolve method has practically disappeared from rebuild
performance profiles.
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.
* Prevent running sudo meteor run it on Unix
Prevent running sudo meteor run it on Unix
Fix for all commands
remove empty line
Revert "Prevent running sudo meteor run it on Unix"
This reverts commit d2867561bb6fb1b259a59556628b56a64c677a0b.
improve PR
improve PR
improve PR
fix PR
* improve PR
* fix PR
* fix PR
* fix PR
I originally added the exception-caching functionality in order to avoid
calling files.stat repeatedly for files known to be missing, but now that
we're using statOrNull, knowledge of missing files (as indicated by
statOrNull returning null) is being properly cached.
The reason it's dangerous to cache exceptions is that (for example) when
an ENOENT exception indicates the file is missing, there will be no more
change events for that file, effectively making the exception permanent,
even if the file comes to exist at a later time.
As a reminder, we use fs.watchFile only as a fallback in environments
where pathwatcher.watch is not available, such as on network or virtual
file systems.
