eslint process returning incorrect exit/error codes

Version

3.4.1

Reproduction link

https://github.com/ffxsam/repro-errors-passing-build

Environment info

  System:
    OS: macOS 10.14.3
    CPU: (12) x64 Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
  Binaries:
    Node: 10.15.0 - ~/.nvm/versions/node/v10.15.0/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.8.0 - ~/.nvm/versions/node/v10.15.0/bin/npm
  Browsers:
    Chrome: 72.0.3626.119
    Firefox: 65.0.1
    Safari: 12.0.3
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0-beta.2
    @vue/babel-plugin-transform-vue-jsx:  1.0.0-beta.2
    @vue/babel-preset-app:  3.4.1
    @vue/babel-preset-jsx:  1.0.0-beta.2
    @vue/babel-sugar-functional-vue:  1.0.0-beta.2
    @vue/babel-sugar-inject-h:  1.0.0-beta.2
    @vue/babel-sugar-v-model:  1.0.0-beta.2
    @vue/babel-sugar-v-on:  1.0.0-beta.2
    @vue/cli-overlay:  3.4.1
    @vue/cli-plugin-babel: ^3.4.0 => 3.4.1
    @vue/cli-plugin-eslint: ^3.4.0 => 3.4.1
    @vue/cli-service: ^3.4.0 => 3.4.1
    @vue/cli-shared-utils:  3.4.1
    @vue/component-compiler-utils:  2.6.0
    @vue/preload-webpack-plugin:  1.1.0
    @vue/web-component-wrapper:  1.2.0
    eslint-plugin-vue: ^5.2.2 => 5.2.2
    vue: ^2.6.6 => 2.6.8
    vue-eslint-parser:  5.0.0
    vue-hot-reload-api:  2.3.3
    vue-loader:  15.7.0
    vue-style-loader:  4.1.2
    vue-template-compiler: ^2.5.21 => 2.6.8
    vue-template-es2015-compiler:  1.9.1
  npmGlobalPackages:
    @vue/cli: 3.4.1

Steps to reproduce

1. yarn
2. yarn build

What is expected?

I expect an error return code (so the CI build would fail)

What is actually happening?

Return code 0 (success) is returned, so app deploys

[yyx990803]

To avoid breaking changes I think it’s better to adjust it to the following:

• "default": emit warnings and warnings and errors as errors (what @ffxsam wants)
• "warnings": emit everything as warnings (avoid errors to pop up in overlay during development)
• "errors": emit everything as errors
• true: same as "warnings" (also same as current behavior so it doesn’t have to be breaking, can be deprecated in next major)

[LinusBorg]

The implementation has a few pounds of historic baggage from the old days of the webpack template, and some issues in making both eslint-loader and friendly-errors-webpack-plugin play nice together.

Additionally, the default of not emitting any errors was chosen so the linting errors doesn’t halt HMR updates during development (See: https://github.com/webpack-contrib/eslint-loader#emitwarning-default-false)

But I think we could try and improve the behaviour for production builds.