No eslint warnings on initial "npm run serve"

[TitanFighter]

Version

3.2.1

Reproduction link

http://no.link

Environment info

  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

Steps to reproduce

1. vue create test or create project in vue ui;
2. Select default template;
3. Open vue ui and in Configuration -> ESLint configuration select config Strongly recommended or Recommended;
4. npm run serve -> no any warnings;
5. Open App.vue, simply re-save it (or make small changes) -> warnings shown.

What is expected?

Terminal should show warnings on initial npm run serve without any additional actions with a files.

What is actually happening?

After npm run serve it is necessary to make any changes with a files in order to get ESLint warnings.

[joshuathompson]

Noticing this as well plus an extra case:

1. Save file with errors while not running
2. npm run serve -> errors are shown
3. Stop serving with ctrl-c
4. npm run serve again and no errors are shown despite nothing changing!

[tmerten]

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 createed) 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).

[jkzing]

@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.😅

[tmerten]

@jkzing Thanks for the heads up. Would you happen to have an idea how to run the cache-loaders 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 ;) ).

[jkzing]

@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.

[tmerten]

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.

[roy-yi]

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.

[hskrishna29]

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?

[phyzical]

As a workaround could you just make a new script ~ "npm run lint --no-fix && npm run serve"