We should never be generating line number comments for server code, since
they can cause problems with multi-line strings, and no one will see those
comments on the server anyway.
The html-scanner tests were breaking because we no longer compile
multi-line template strings for Node 8, yet we were annotating every line
with a line number comment (because we had a source map), and lines within
multi-line template strings were getting comments appended to them, which
thus became an observable part of the string.
On the client, we still compile template strings to normal string
literals, so the line number annotations are not a problem (for now).
Related to https://github.com/meteor/meteor/pull/8728#issue-232369984,
though these changes apply only to the meteor/tools codebase. We still
need to make similar changes to the babel-compiler package so that
application code will benefit.
The assumption that we're using Node 8 also allows some simplifications to
the runtime polyfills that we use.
The pull request corresponding to our fork is not going to be merged, so
it's better to use the alternative this.finished API available in newer
versions of the upstream package.
https://github.com/williamkapke/node-eachline/pull/4
With Meteor 1.6 / Node 8, I noticed _buildLocalPackages taking multiple
seconds on initial server startup and restart, and the problem seems to be
that we call the global.gc function too often. This wasn't a problem in
previous versions of Node, as far as I know, but it makes sense to heed
the comment in tools/utils/gc.js, now that it matters.
The pull request corresponding to our fork is not going to be merged, so
it's better to use the alternative this.finished API available in newer
versions of the upstream package.
https://github.com/williamkapke/node-eachline/pull/4
Note that eee519ad58 greatly reduced the
TIMEOUT_SCALE_FACTOR for Circle CI tests, which likely caused some tests
to time out more often, so these additional timeouts are really just a way
of re-bumping individual timeouts, which arguably leaves the test suite in
a better overall state of health.
Though they don't appear to actually be used anywhere by Meteor, it's
probably worth preserving them in case they are somehow exposed
elsewhere. Static class properties would avoid this, but the TC39
proposal is still progressing.
This restores the behavior of 8c70716954 by
default, with the option of disabling the prioritized file watching system
by setting METEOR_WATCH_PRIORITIZE_CHANGED explicitly to "false".
The self-tests where the environment variable is explicitly set form a
nice to-do list of tests that should be improved to be more robust to cope
with differences in file watcher timing.
Helps with #8648 and similar issues.
Although I think 8c70716954 is a good idea
in practice, it altered the timing of self-tests enough to cause a number
of failures, so for now that behavior will be gated behind the environment
variable METEOR_WATCH_PRIORITIZE_CHANGED.
This drastically reduces the number of open file descriptors by not
preemptively acquiring a file descriptor for every watched file.
The downside is that the first time you edit a particular file, you may
have to wait up to DEFAULT_POLLING_INTERVAL milliseconds before Meteor
notices the change. The upside is that changes will be detected
instantaneously for that file in the future, even after restart.
If holding open too many file descriptors is indeed a contributing factor
to issues such as #8648, then this change should go a long way towards
mitigating those problems.
cc @abernix @hwillson
If a package has a semantic (x.y.z) version in npm-shrinkwrap.json, npm
appears to install it always from the npm registry, rather than the
original tarball URL (uncommon but used by the less and stylus Meteor
packages, among others).
