I noticed recently that progress messages were no longer displayed (though
the ASCII spinner was still animating). I bisected the problem to the
progress.ts conversion in #10650, and I attempted to reproduce the
conversion, step by step. The problem ended up being the renaming of
._title to .title, which was a mistake because external code accesses
progress._title. Once I updated those invasive access points, progress
messages began displaying once again.
Console.isInteractive() will be false during our Circle CI test runs,
since we set the METEOR_HEADLESS environment variable, so this change
should help prevent spurious test failures like these:
https://circleci.com/gh/meteor/meteor/15305.
This adds a memoized helper function for detecting Emacs throughout the
CLI tool and automatically resorts to "ProgressDisplayStatus" mode when
Emacs is enabled.
In my tests with both Emacs 22 and 27, this nearly doubled performance
when using Meteor from within the Emacs shell (i.e. `M-x shell`).
I think this was originally designed for Emacs shell but at some point Emacs or
Node improved so that Node finds columns for Emacs shell and switches to the
full display.
Switching to the status-only display leads to massive speedups when doing builds
in my Emacs shell.
If a login token is expired, or no longer valid, make sure that Meteor doesn't
just sit there at a login prompt that the user can't see.
This currently only applies if `headless` mode is enabled, though a follow-up
to this commit might consider setting `headless = true` automatically
in a CI environment using environment variables such as: `CI`, `TRAVIS`,
`JENKINS_URL`, etc., as the npm-registry-client does in a similar way.
See: https://github.com/npm/npm-registry-client/pull/129/filesFixes#8839.
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.
