* Call process.stdout._handle.setBlocking(true)
This prevents output from being truncated when the compiler can output
errors to stdout faster than it can receive them. This may slow down
performance for compilations for many errors, but those were already
quite slow.
* Disable tslint no-unnnecessary-type-assertion-2
It is wrong. It *is* necessary.
* Resolve config wildcards result order in a platform independent manner
* Accept affected user test baseline
* Per reccomendation, just change matchFiles
* Add test asserting the same order on differing case sensitive platforms
1. Add documentation
2. Better organisation of concerns in utility functions
3. Better handling of module.exports and exports in the binder's new
code.
This way when resources are in use (eg, at midnight when many cron jobs get run) the CI server is less likely to timeout due to resource starvation.
This is pretty much an analogue to the recent travis PR; it just doesn't happen as often on circle (seems like it's only happened while executing `user` tests during `cron`).
* Update baselines for user tests
* Add explicit indentation
* Fix https://github.com/Microsoft/TypeScript/issues/21355: Format `// @ts-ignore` added by quick fix
* Extract check to a separate function
* Consolidate checking for valid insert location
* Code review comments
* Do not return makeChange
* Apply 'no-unnecessary-initializer' lint rule
Forbids `let`/`const` statements to be initialized to `undefined`, since that's the initial value by default anyway.
The auto-fixer also happened to remove two unnecessary `as number` casts in `src/harness/parallel/worker.ts`.
For historical data: to run with `--fix`, I modified the line in `Jakefile.js` that declared the `cmd` for running TSLint.
* Moved worker.ts type assertions to parameters
* Make test timeout on travis huge
Specifically, 10 minutes, which is the duration it can go before travis itself will time out (if there is not output). This is needed because we set `workerCount=3` to improve our runtime, however travis doesn't _always_ have that much compute available; so when travis is resource-starved and we're running on one real thread, two test runners sit idle (due to resource starvation) and get timed-out by the watchdog process during test running. This timeout should be long enough that such that timeouts no longer occur on travis.
* Update .travis.yml
