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.
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.
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.
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.
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 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.
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.
