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