Compilation progress is always displayed to stderr

Do you want to request a feature or report a bug?

Not sure, it could be considered as a feature or as a bug. For certainty, let’s call it a bug, because messages written to stderr are expected to be errors (IMHO).

What is the current behavior?
According to documentation and code, compilation progress is written to stderr.

If the current behavior is a bug, please provide the steps to reproduce.

git clone https://github.com/Jaben/angular-webpack-workflow
cd angular-webpack-workflow
npm install

Run “dev” npm script in IntelliJ IDE (e.g. WebStorm 2016.3.2) using UI:

  • open package.json
  • right-click “dev” script and select “Run dev”

webpack-console

What is the expected behavior?
Compilation progress is shown as normal text (not red).

If this is a feature request, what is motivation or use case for changing the behavior?
Not sure about the request status (feature vs bug). As for the motivation, it’s about having normal text output in console. Otherwise, users might think that something wrong happened (which is not true).

Are there any reasons to not display the progress to stdout? If there are, what do you think about making it configurable via some environment variable maybe? Thanks!

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.
Not known to me

Author: Fantashit

6 thoughts on “Compilation progress is always displayed to stderr

  1. POSIX defines:

    • standard output = for writing conventional output
    • standard error = for writing diagnostic output

    progress is a diagnostic output so it belongs to standard error.

  2. @sokra
    I don’t share the opinion that progress output is diagnostic.

    From my point of view “diagnostic” is related to bug finding or error analysis. Hence it makes sense to output it on stderr. A progress display however is on informational level and should be rendered to stdout.

    Printing non-error-ouput on stderr makes trouble:
    In WebStorm for example you get the progress output rendered to stderr all in red color. So everything looks like an error.
    This is quite disturbing for the user. One cannot tell status messages from “real” errors because they all appear in red.

  3. I don’t share the opinion that progress output is diagnostic.

    Nor do I. Also, directing ordinary progress output and error reporting to the same place makes some extremely useful command-line workflows impossible. For example, redirecting non-error build output to /dev/null while running a test suite in watch mode and only seeing build errors and test output is impossible.

  4. This makes little sense to use stderr. A plain .NET Core dotnet new angular app upgraded to Angular 8 (which uses Webpack) and setting progress: true in the angular.json causes pages and pages of output like this on the app startup:

    image

    This makes progress: true quite useless as I’ll be ignoring its ouput…

  5. Any fix for this? I keep explaining that this is not an error, but anyways, the partner sees ERROR in the output and is asking for a fix.

  6. This issue is nowhere near resolved, and it’s fantastically annoying. On every run my console gets spammed with red FAIL messages, and it’s impossible to spot any real errors in all that mess, making the entire feature completely useless!

    Whoever thought this was a good idea have completely misunderstood the meaning and purpose of stderr. That POSIX interpretation is just asinine.

    @sokra said:

    POSIX defines:

    * standard output = for writing conventional output
    * standard error = for writing diagnostic output
    

    progress is a diagnostic output so it belongs to standard error.

    So, according to the same interpretation, information about what a program is currently doing is considered unconventional?!
    Wait, have you forgotten I could use any printed information to diagnose something? Let’s get rid of stdout altogether and only use stderr for everything! 🤡

    Someone please fix this.

Comments are closed.