Skip to content

app.js content hash depends on project path when using router + vuex + config in package.json #3533

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
antoinematyja opened this issue Feb 27, 2019 · 9 comments

Comments

@antoinematyja
Copy link

Version

3.4.1

Environment info

  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i7-6567U CPU @ 3.30GHz
  Binaries:
    Node: 10.15.0 - /usr/local/bin/node
    Yarn: 1.5.1 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 72.0.3626.119
    Firefox: 61.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.1 => 3.4.1 
    @vue/cli-plugin-eslint: ^3.4.1 => 3.4.1 
    @vue/cli-service: ^3.4.1 => 3.4.1 
    @vue/cli-shared-utils:  3.4.1 
    @vue/component-compiler-utils:  2.6.0 
    @vue/eslint-config-standard: ^4.0.0 => 4.0.0 
    @vue/preload-webpack-plugin:  1.1.0 
    @vue/web-component-wrapper:  1.2.0 
    babel-helper-vue-jsx-merge-props:  2.0.3 
    eslint-plugin-vue: ^5.0.0 => 5.1.0 
    vue: ^2.5.21 => 2.5.22 
    vue-content-loader: ^0.2.1 => 0.2.1 
    vue-eslint-parser:  2.0.3 
    vue-googlemaps: ^0.1.2 => 0.1.2 
    vue-hot-reload-api:  2.3.3 
    vue-i18n: ^8.7.0 => 8.7.0 
    vue-loader:  15.6.4 
    vue-observe-visibility:  0.3.1 
    vue-resize:  0.4.5 
    vue-router: ^3.0.1 => 3.0.2 
    vue-style-loader:  4.1.2 
    vue-template-compiler: ^2.5.21 => 2.5.22 
    vue-template-es2015-compiler:  1.9.1 
    vuex: ^3.0.1 => 3.0.1 
    vuex-router-sync: ^5.0.0 => 5.0.0 
  npmGlobalPackages:
    @vue/cli: 3.4.0

Steps to reproduce

  • Create a vue-cli project
vue create testapp
  • Select manually features, add router + vuex, then keep everything as default ; at the last choice, select "In package.json" instead of dedicated config files
  • Run build and look at the dist/js/app.js content hash
cd testapp
npm run build
  • Rename the project folder and build again
cd ..
mv testapp testapp2
cd testapp2
npm run build
  • Compare the dist/js/app.js content hash with the previous one, it should be different

What is expected?

Content hash should be the same

What is actually happening?

Content hash is different


  • It only happens with the combo "router + vuex + config in package.json" ; it doesn't happen with "router + config in package.json" or "vuex + config in package.json" (which is super weird)
  • It only affects app.js (and app.js.map), css files are ok

Use case:
I have a vue app deployed with capistrano on 2 different VMs.
At each deploy, on each VM:

  • A new directory is created with the date in its name (ex: /home/user/releases/20190227110836)
  • The project code is fetch from git in this directory
  • npm run build is run

If the directories are not created at the same time, they will have different names, which will generate different content hashes on my app.js on each VM.

@haoqunjiang
Copy link
Member

Is this related d5ed280 ?

@antoinematyja
Copy link
Author

Nope
The issue looks the same as #2807
But I already upgraded to vue-cli 3.4.1 and it's still happening.

@haoqunjiang
Copy link
Member

I mean, you can now apply the absoluteRuntime: false option to the preset now. We didn't document it, though.

@antoinematyja
Copy link
Author

Oh ok I thought false was the new default. Don't know where to put this option though.

Also it's still weird that the issue doesn't happen with the config in separate files, but happens with the config in package.json.

@haoqunjiang
Copy link
Member

// babel.config.js
module.exports = {
  presets: [
    ['@vue/app', {
      absoluteRuntime: false
    }]
  ]
}

@antoinematyja
Copy link
Author

Many thanks, I was trying hard stuff like

presets: [
  '@vue/app', {
    absoluteRuntime: false
  }
]

Now it works perfectly.

Still confused about why it happens with this configuration only.
Also I think this should be the default behavior.

Feel free to close this issue if this isn't relevant.

@haoqunjiang
Copy link
Member

Also it's still weird that the issue doesn't happen with the config in separate files, but happens with the config in package.json.

Just figured it out. It is related to this bug: #2983 and is expected to be fixed in v3.5.
For now a workaround is to disable thread-loader by adding the following configuration to vue.config.js:

module.exports = {
  parallel: false
}

I'll close this issue as it's now a duplication of #2983.


Also I think this should be the default behavior.

We can't because we can't be sure if the @babel/runtime-corejs2 in the root node_modules is the correct version, due to the non-deterministic nature of npm dependency hoisting. So we have to leave it for the user to decide.

@antoinematyja
Copy link
Author

Just tried to reproduce this with the new v3.5, I confirm it's no longer happening 🥇

@antoinematyja
Copy link
Author

antoinematyja commented Mar 27, 2019

@sodatea Sadly the issue came back with v3.5.1.

I tried several combos to find the specific package/version reintroducing the issue and the culprit is @vue/[email protected]. The latest version 3.5.3 still has the issue.

    "@vue/cli-plugin-babel": "^3.5.3",
    "@vue/cli-plugin-eslint": "^3.5.1",
    "@vue/cli-service": "^3.5.0",

=> ✅

    "@vue/cli-plugin-babel": "^3.5.3",
    "@vue/cli-plugin-eslint": "^3.5.1",
    "@vue/cli-service": "^3.5.1",

=> ❌

(also it seems like the npm package @vue/cli-plugin-eslint got stuck in 3.5.1 when others got to 3.5.3)

I understand this issue is difficult to reproduce but it would be great to have a test to avoid reintroducing it in the future as it can be critical for production environment builds.

Thanks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants