vue-cli: 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
- yarn
- 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
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 16 (15 by maintainers)
Commits related to this issue
- feat: add 3rd option to `lintOnSave` to support 'default' behaviour (fix #3552) (#3572) — committed to vuejs/vue-cli by LinusBorg 5 years ago
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 errorstrue: same as"warnings"(also same as current behavior so it doesn’t have to be breaking, can be deprecated in next major)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.
@sodatea The behavior with
lintOnSave: 'error'is still broken.yarn serveyarn buildto failThis is not handled properly. Warnings are just that: warnings.
According to the eslint docs (emphasis mine):
In case this helps others who happen upon this thread from Googling:
Setting
lintOnSavetodefaultdid not work for me as I still got an exit code of0even though the linter found errors that it auto-fixed as part of the pipeline.So I ended up running the lint command with these flags on the pipeline to get the appropriate error code:
vue-cli-service lint --max-warnings 0 --no-fixHope that helps 😃
Thanks for taking a look. I’ll look at that webpack config.
But besides that, I’m speaking of the vue-cli developer experience out of the box. The way eslint behaves is incorrect and shouldn’t require any config for it to work the way it should.
https://cli.vuejs.org/config/#lintonsave