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.
Since the -beta152.1 suffix is redundant with the meteor-tool version and
the release version, I'm using just -beta.1 for those versions, but I'm
using -beta152.1 for all other package versions, to avoid overlap with
versions previously published on the release-1.6 branch.
Since the beta versions of these packages are likely to overlap with
previously published beta versions on the release-1.6 branch, we should be
sure to use a distinct suffix like -beta152.n.
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 1.6-beta.7 release had a version conflict because of the webapp@1.3.17
constraint in server-render/package.js. I noticed the problem before
publishing the release, so we will just skip to 1.6-beta.8.
