"Building for Production" message is delivered on stderr channel

[lain-d]

Version

3.9.3

Environment info

Environment Info:


  System:
    OS: macOS Sierra 10.12.6
    CPU: (24) x64 Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
  Binaries:
    Node: 10.16.0 - /usr/local/bin/node
    Yarn: Not Found
    npm: 6.9.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 75.0.3770.142
    Firefox: Not Found
    Safari: 12.1.1
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0 
    @vue/babel-plugin-transform-vue-jsx:  1.0.0 
    @vue/babel-preset-app:  3.9.2 
    @vue/babel-preset-jsx:  1.0.0 
    @vue/babel-sugar-functional-vue:  1.0.0 
    @vue/babel-sugar-inject-h:  1.0.0 
    @vue/babel-sugar-v-model:  1.0.0 
    @vue/babel-sugar-v-on:  1.0.0 
    @vue/cli-overlay:  3.9.0 
    @vue/cli-plugin-babel: ^3.9.0 => 3.9.2 
    @vue/cli-plugin-eslint: ^3.9.0 => 3.9.2 
    @vue/cli-service: ^3.9.0 => 3.9.3 
    @vue/cli-shared-utils:  3.9.0 
    @vue/component-compiler-utils:  2.6.0 (3.0.0)
    @vue/preload-webpack-plugin:  1.1.0 
    @vue/web-component-wrapper:  1.2.0 
    eslint-plugin-vue: ^5.0.0 => 5.2.3 (4.7.1)
    vue: ^2.6.10 => 2.6.10 
    vue-analytics: ^5.17.0 => 5.17.0 
    vue-axios: ^2.1.4 => 2.1.4 
    vue-eslint-parser:  2.0.3 (5.0.0)
    vue-gtm: ^2.0.0 => 2.0.0 
    vue-hot-reload-api:  2.3.3 
    vue-loader:  15.7.1 
    vue-style-loader:  4.1.2 
    vue-template-compiler: ^2.6.10 => 2.6.10 
    vue-template-es2015-compiler:  1.9.1 
  npmGlobalPackages:
    @vue/cli: 3.9.3

Steps to reproduce

const ls = spawn('npm', ['run', ''build']);
ls.stdout.on('data', (data) => {
  console.log(`stdout: ${data}`);
});
ls.stderr.on('data', (data) => {
  console.log(`stderr: ${data}`);
});

ls.on('close', (code) => {
  console.log(`child process exited with code ${code}`);
});

What is expected?

stdout: - Building for production...

What is actually happening?

stderr: - Building for production...

---

All other output is coming on the correct stdout channel, however for some reason the building for production message gets delivered via the error channel. This makes running automated builds from the command line difficult, as it erroneously reports a stderr

[haoqunjiang]

I'm not sure if it should be considered a bug.
See sindresorhus/ora#85 (comment)

The reason it's stderr is so that it will not interfere with normal output. Most other spinners use stderr too.

See also sloria/konch#66 for some more common practices.

Nonetheless, the command line outputs in Vue CLI is now a little bit messy.
That could be improved.

[9-lives]

That makes sense.

[boardend]

It would be nice to deactivate the spinner (and print everything to stdout) via a vue.config.js or a global command line option.

The spinner is fine if you invoke Vue CLI on one project directly. But if you build multiple Vue CLI projects together (in my case a monorepo managed by Rush.js) the spinner makes things really messy, especially since Rush began to treat everything on stderr as warning (Rush.js > 5.7.x).

Links:

• [rush] Rush returns a zero exit code when build succeeds with warnings. microsoft/rushstack#1329
• [rush] Simplify setting allowWarningsInSuccessfulBuild for build and rebuild commands microsoft/rushstack#1375

[lain-d]

I'm in a similar situation as @boardend which is what sparked the initial discussion here. A --quiet or --silent flag for vue-cli would be quite useful for this type of scenario.

[wbern]

While I think it is really annoying that @vue/cli does not have a simple way to fix this, here's another shell-based workaround I can share here.

Just put 2>&1 at the end of your package.json script, or when executing in the shell. This will redirect stderr to stdout, and rushjs (which I am also using) won't bail the incremental builds.

This will prevent any stderr output from failing rushjs incremental building, but at least the stderr output will still be shown (as stdout).

Example:

"scripts": {
    ...
    "build": "vue-cli-service build 2>&1",
    ...
}

[jasonkarns]

"Building for production" is diagnostic output and should be going to stderr.

[boardend]

"Building for production" is diagnostic output and should be going to stderr.

I agree (if there is a way to silence this "diagnostic output" by setting the log level / a --silent flag...)

[jasonkarns]

if there is a way to silence this "diagnostic output"

@boardend vue-cli-service build 2>/dev/null 😸

[boardend]

Nope, I still want any warning/error on stderr... I'm asking for a way to turn this "diagnostic output" off, or move it to the stdout stream.

The output/spinner on stderr is fine if you invoke npm run serve on a single Vue CLI package, but if you build multiple packages with Rush/Lerna/... , it would be really usefull to treat everything on stderr at least as a warning. (Basically I'm asking for a flag that does the same as VUE_CLI_TEST at packages/@vue/cli-shared-utils/lib/spinner.js#L62 , but without all the other effects VUE_CLI_TEST brings with it...)

[octogonz]

Rush is a build orchestrator that invokes other tools. As such, it needs a generic way to distinguish warnings from informational logging. Its convention is:

• "Failed": When invoking the build script for a project, if the process exit code is nonzero, it is interpreted as a failure. Rush won't attempt to build downstream projects. Any STDERR output is displayed as an error message.
• "Completed-with-Warnings": If the build script returns a zero exit code, but printed something on STDERR, then the STDERR content is interpreted as warnings. Warnings don't prevent downstream projects from getting built. But these warnings cause the overall job to fail; the developer must eliminate the warnings before they can merge their PR.
• "Success": If the build script returns a zero exit code and does not print anything on STDERR, this is interpreted as success. In order for the overall job to succeed, there must be no STDERR output from any build script.

Obviously different tools have different ways of using STDERR (and often a logging system with errors and warnings). Rush expects the toolchain to adapt the tool's output to fulfill the above contract. For example with Jest, we provide a Jest reporter that suppresses nonessential STDERR messages.

Another possible design would be to implement a programmatic API for logging. However this would require each tool to implement that API. The STDERR convention is simpler and in most cases can be implemented without any special wrappers.

Vue CLI doesn't have any obligation to implement Rush's contract. But it would make life easier if Vue had an option like --only-print-errors-on-stderr. :-)

[jrummell]

This is also an issue when running a CI build and failing the build based on stderr output. We were really surprised that Building for production... broke our build.

[jasonkarns]

@jrummell As a general rule, it's not safe to assume that data on the stderr stream means failure. It's completely valid and expected for diagnostic output to go to stderr.

[jrummell]

@jrummell As a general rule, it's not safe to assume that data on the stderr stream means failure. It's completely valid and expected for diagnostic output to go to stderr.

I wouldn't have expected that ... I see that this is a common pattern. Personally, it just feels wrong to output non-errors to stderr, because well, they are not errors. This is good information though.