3.2.1
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz
Binaries:
Node: 10.14.0 - /usr/bin/node
Yarn: Not Found
npm: 6.4.1 - /usr/local/bin/npm
Browsers:
Chrome: 70.0.3538.110
Firefox: 63.0.3
npmPackages:
@vue/babel-preset-app: 3.2.0
@vue/cli-overlay: 3.2.0
@vue/cli-plugin-babel: ^3.2.0 => 3.2.0
@vue/cli-plugin-eslint: ^3.2.0 => 3.2.1
@vue/cli-service: ^3.2.0 => 3.2.0
@vue/cli-shared-utils: 3.2.0
@vue/component-compiler-utils: 2.3.0
@vue/preload-webpack-plugin: 1.1.0
@vue/web-component-wrapper: 1.2.0
babel-helper-vue-jsx-merge-props: 2.0.3
babel-plugin-transform-vue-jsx: 4.0.1
eslint-plugin-vue: ^5.0.0-0 => 5.0.0-beta.5
vue: ^2.5.17 => 2.5.17
vue-eslint-parser: 2.0.3
vue-hot-reload-api: 2.3.1
vue-loader: 15.4.2
vue-style-loader: 4.1.2
vue-template-compiler: ^2.5.17 => 2.5.17
vue-template-es2015-compiler: 1.6.0
npmGlobalPackages:
@vue/cli: 3.2.1
vue create test
or create project in vue ui
;default
template;vue ui
and in Configuration -> ESLint configuration
select config Strongly recommended
or Recommended
;npm run serve
-> no any warnings;App.vue
, simply re-save it (or make small changes) -> warnings shown.Terminal should show warnings on initial npm run serve
without any additional actions with a files.
After npm run serve
it is necessary to make any changes with a files in order to get ESLint warnings.
Noticing this as well plus an extra case:
npm run serve
-> errors are shownctrl-c
npm run serve
again and no errors are shown despite nothing changing!I am noticing the exact same problem as @joshuathompson running yarn serve
.
However, this happens only when I run our entire codebase. I cannot reproduce it in an "empty" (freshly vue create
ed) project by copying over package json
and vue.config
. Thus, _I assume_ it to be related to how the Vue app is initialized in main.js
and/or App.vue
.
Does somebody know: Is there anything that gets permanently "initialized" on the first run/build?
After some debugging, I found that at first yarn serve
the directories and files node_modules/.cache/babel-loader/*.json
, node_modules/.cache/eslint-loader/*.json.gz
, and node_modules/.cache/vue-loader/*.json
are being crated (and relied upon on the second run).
This makes sence, since the errors in the first run are mainly problems where eslint thinks that components/variables are registered but not used. On the second run this info is in the cache.
Finally: A ./node_modules/.bin/vue-cli-service lint --no-fix
always gives me the errors I see in the first run (I was hoping this builds up the cache and I can run it once as a workaround).
@tmerten Thanks for the clue, you are right it have something to do with the cache .
In more detail, we are using cache-loader
to cache results for some expensive loaders (babel-loader
, vue-loader
, ts-loader
). And eslint-loader
is enforced to be performed in pre
stage which is before above loaders (with cache). So the cache of those loaders will cause eslint-loader
being skipped. Which results in the eslint check would always be successful while the cache is still valid.
I have tried to think about it but didn't come up with a solution.馃槄
@jkzing Thanks for the heads up. Would you happen to have an idea how to run the cache-loader
s manually (or maybe fire all of them up for linting)?
That would be a workaround for me.
Just to give some context info why I am struggling with this: We are developing in docker containers and in there, the cache is never generated (vue-cli-service serve
is run only once). This results in a lot of irrelevant errors (well there are workarounds for this such as storing the cache in a persistent volume, but, well,... those are workarounds ;) ).
@tmerten Hmm...I might not fully understand your scenario.
When using a docker for development, if every time you start up with a fresh container, it should not have the cache problem above I mentioned.
Actually I have tested it with a simple dockerfile:
FROM node:latest
RUN mkdir -p /test-lint
WORKDIR /test-lint
COPY package.json /test-lint/package.json
RUN npm i
COPY . /test-lint
EXPOSE 3000
CMD ["npm", "run", "serve"]
This results in a lot of irrelevant errors
I guess maybe you don't want to see any eslint errors on first build with serve
command?
If that is your case, you can select Lint and fix on commit
while creating the project. Which won't add eslint-loader
to lint your code in webpack build and will lint you code just before your commit is created.
Err. Sorry for the confusion. I happen to have a different problem than the original one, which seems to be related (maybe the issue can be split in two, actually). It was described originally in the comment by @joshuathompson above.
To summarize: I see "random" errors (mainly things like var defined but never used
or component registered but not used
) in the first run when initializing a rather large project. From the second run (when the cache is initialized) the messages are gone. That is why it is a problem in docker.
@jkzing I can open fresh issue for that if it is not related.
I also encountered this problem. When first run npm run build
, I can see warnings and errors. But when second run, they disappeared.
npm run lint --no-fix will always show errors and warnings.
May I know when will this bug be fixed? Thx.
any update on this? I want npm run build
to fail in case of any lint errors. npm run lint --no-fix
consistently gives out the errors, however this does not happen with npm run build
.
Is this bug going to be fixed, or is there any other way to go about it?
As a workaround could you just make a new script ~ "npm run lint --no-fix && npm run serve"
I have this issue, where when pulling a branch. I would get linter errors on serve
Then when i exit and run it for the second time, no linter errors would be shown
I used a similar trick to https://github.com/vuejs/vue-cli/issues/3065#issuecomment-454337343 but, in my case at least, I only needed to clear the vue-loader
cache. So instead of doing this:
"serve": "vue-cli-service serve",
I do:
"serve": "rimraf -rf ./node_modules/.cache/vue-loader && vue-cli-service serve",
This worked fo me.
adding following to vue.config.js: module.exports = { lintOnSave: false, }
from @progsri here
https://github.com/vuejs/vue/issues/10226#issuecomment-519536227
it works !
clear the cache before run serve.
"serve": "rimraf -rf ./node_modules/.cache/vue-loader && vue-cli-service serve",
it works !
clear the cache before run serve.
"serve": "rimraf -rf ./node_modules/.cache/vue-loader && vue-cli-service serve",
Removing the vue-loader cache don't work for me...
For our project, you have to remove the entire /.cache/ folder and not just /.cache/vue-loader for this to work reliably.
Working, but removing the cache is just a temporary workaround and make serving the app slower, obviously :) Any news about this issue?
Still an issue for almost 2 years now.
Most helpful comment
I used a similar trick to https://github.com/vuejs/vue-cli/issues/3065#issuecomment-454337343 but, in my case at least, I only needed to clear the
vue-loader
cache. So instead of doing this:I do: