vue-cli-service build does not update or invalidate node_modules/.cache, resulting in broken build

[marosivanco]

Version

3.0.1

Node and OS info

node v8.9.3 / npm 6.4.1 / Windows 10

Steps to reproduce

I have the app A which has dependency B.
A uses B's sources, thus B is in vue.config.js as transpiled:

transpileDependencies: ["B"]

• in A: vue-cli-service build --modern builds app and creates node_modules/.cache
• in B: change code, increase version, and publish it to npm repo
• in A: change B's version in package.json
• in A: npm update B, which updates node_modules/B
• in A: increase version
• in A: vue-cli-service build --modern

What is expected?

A/dist should correspond to A's and B's sources.

What is actually happening?

A/dist is the same (same hashes, same content), as in the previous build

---

If I manually delete node_modules/.cache, and run the build again, then it works - the dist content corresponds to the sources.

[LinusBorg]

Please provide a reproduction as required in the issue form that you filled out.

[marosivanco]

The reproduction requires more then one repository and publishing to npm. I was hoping for an aha effect, but ok, I will try to create some sort of reproduction.
Is it ok if I attach zip with both projects?

[LinusBorg]

that would be apprechiated, yes. a github repository (with both projects in subfolders) would be even easier.

[marosivanco]

Here is the zip with both projects reproduction.zip
Note on how I created it:

• vue create a - using default template
• vue create b - using default template
• I deleted .git repo, and node_modules, but left package-lock.json so you can see what has been actually used.

In b:

• removed private flag from package.json and added publishConfig to specify private npm repository
• edited @/src/components/HellowWorld.vue to see its version - added B@0.1.0 after msg
• npm publish

In a:

• npm install b --save
• in app.vue changed import HelloWorld from "b/src/components/HelloWorld.vue";
• npm run build
• deployed dist to my webserver, index.html shows text: Welcome to Your Vue.js App B@0.1.0

OK so far, now the change:

In b:

• edited @/src/components/HellowWorld.vue to see its version - added B@0.2.0 after msg
• npm version minor
• npm publish

In a:

• edited package.json, updated b's version pattern to "^0.2.0"
• npm update b (after completion, node_modules/b is in version 0.2.0)
• npm run build
• deployed dist to my webserver, index.html shows text: Welcome to Your Vue.js App B@0.1.0

Not OK, the text should display B@0.2.0. But when I delete cache:

In a:

• delete node_modules/.cache
• npm run build
• deployed dist to my webserver, index.html shows text: Welcome to Your Vue.js App B@0.2.0

Which is expected behavior.

[neemzy]

FWIW, we have the same problem when updating packages containing custom Vue components, even in development. Old versions are still displayed until we nuke the cache.

[marosivanco]

Workaround:
npm install rimraf --save-dev

In package.json add the prebuild script:

...
"prebuild": "node ./node_modules/rimraf/bin.js ./node_modules/.cache",
"build": "vue-cli-service build --modern",
..

Kind of clumsy, but better than corrupted build.

[jfuehner]

I too experienced this issue with a node_module package containing vue components. None of the consuming projects of that node_module package were being updated even though npm update was ran on the project and the latest version was downloaded.

Once I rimraf ./node_modules/.cache things were updated.

[LinusBorg]

"There are two hard problems in programming: naming things, and caching."

What options do we have?

• We could add package.json's dependencies, devDependencies and peerDependencies fields as inputs to the chache-key generating code (e.g. here. But that wouldn't work for updated nested dependencies (i.e. clearing yarn.lock and reinstalling, adding updated dependencies in the process
• We could add a postinstall script that purges the cache whenever anything is installed into the project (is that possible?)
• We could document this, and add a command/flag to easily purge the cache manually (vue-cli-service build --clearCache or something).

Other ideas? @sodatea

[marosivanco]

• We could clear cache prior build. And add (and document) a command/flag to easily enable the cache manually (vue-cli-service build --enableCache or something).

This way (and also the postinstall script option) the generated project would work out of box, even for the source dependencies.
Current behavior is nasty in a way, that you know there is an issue, only after the build lands the test environment. And even then it is difficult to link it to the cache.

[LinusBorg]

I am having bad cache problems too.

That doesn't really tell us much, I have to say ...