Skip to content

Terse mode output from tsc --build #25562

Open
@RyanCavanaugh

Description

@RyanCavanaugh

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)

Metadata

Metadata

Assignees

No one assigned

    Labels

    In DiscussionNot yet reached consensusSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions