Terse mode output from tsc --build
· Issue #25562 · microsoft/TypeScript (original) (raw)
Search Terms
tsc --build mode console logging output verbose
Suggestion
Have a middle-ground between verbose
and "nothing" when running tsc -b
Use Cases
Initial feedback was that "tsc -b
should print nothing by default (if there are no errors)", which is a reasonable first principle to work from. However, it's nice to have some rough idea of what's going on, especially because a tsc -b
invocation might take quite a while, depending on what's up to date.
Users today can get more output by running with --verbose
, which prints some fairly detailed spew:
message TS6350: Project 'tsconfig.json' is out of date because oldest output 'lib/fetch.js' is older than newest input 'src/fetch.ts'
The verbose
output was written primarily as an "Explain why something is happening"; there is no in-between setting that says simply "Explain what is happening".
This is compounded under --watch
where tsc -b
prints errors, but doesn't print "No errors", so you can't really know if your compilation succeeded or if tsc simply missed a file change.
Proposal
--terse
strikes a middle ground between the default (silent) and verbose
. Its short name would be -t
which doesn't conflict with anything I can think of adding in the near term.
Examples
> tsc -b -t src
message TS6350: 'src/compiler' is up-to-date
message TS6350: 'src/services' is up-to-date
message TS6351: Building 'src/server'...
message TS6351: Building 'src/tests'...
message TS6352: Build completed
> tsc -b -t -w src
message TS6350: All projects are up to date
message TS6351: 'src/compiler' was modified, building...
src/compiler/parser.ts:21:1 - error TS1128: Declaration or statement expected.
21 ?
~
message TS6351: 'src/compiler' was modified, building...
message TS6351: Building 'src/server'...
message TS6351: Building 'src/tests'...
message TS6352: All projects are up to date
Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript / JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. new expression-level syntax)