fix(types): sync vue type augmentations with Vue 2.7

[rchl]

🔗 Linked issue

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Fixing an error:

../../node_modules/@nuxt/types/app/vue.d.ts:21:13 - error TS2428: All declarations of 'ComponentOptions' must have identical type parameters.

21   interface ComponentOptions<

../../node_modules/vue/types/options.d.ts:168:18 - error TS2428: All declarations of 'ComponentOptions' must have identical type parameters.

168 export interface ComponentOptions<
                     ~~~~~~~~~~~~~~~~

Note that I haven't tested this probably and I admit I don't fully understand the intentions here so this needs some testing.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[rchl]

Might also be that it is (needs to be?) different for Vue 2.6...?

[rchl]

As mentioned in #9239, I've verified that this issue happens in Vue 2.7 but not in Vue 2.6.

Are we fine with going forward with types being only Vue 2.7-compatible? It might be the case already as Nuxt ships with VueRouter version that relies on Vue 2.7 and there are also issues with importing Vuex in this package when using Vue 2.6.

node_modules/@nuxt/types/app/index.d.ts:5:28 - error TS2307: Cannot find module 'vuex' or its corresponding type declarations.

5 import type { Store } from 'vuex'

So, either we just revert #9230 or take this PR which reverts the breaking change but leaves some parts of the original change or we could go with something like rchl@0feb9fe which adapts the original changes to make them Vue 2.7 compatible and preserve the functionality that it added.

[codecov-commenter]

Codecov Report

Patch and project coverage have no change.

Comparison is base (7576a98) 66.18% compared to head (ae3f36d) 66.18%.

❗ Current head ae3f36d differs from pull request most recent head f2a2246. Consider uploading reports for the commit f2a2246 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##              2.x   #19526   +/-   ##
=======================================
  Coverage   66.18%   66.18%           
=======================================
  Files          93       93           
  Lines        4096     4096           
  Branches     1158     1158           
=======================================
  Hits         2711     2711           
  Misses       1119     1119           
  Partials      266      266           

Flag	Coverage Δ
unittests	66.18% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[rchl]

Just for the record (since we're discussing this in private anyway): with the current state of the code the inferring of types of properties returned from asyncData (the intent of the original #9239 fix) still doesn't work.

[danielroe]

That is a different issue, and not caused by the fix I pushed here, which is correct as far as I can tell, but rather by the fact that there are other parts of these declarations that also need to be updated to work with Vue 2.7.

[rchl]

I know but we have two ways we can go here. Either just fix the crash or fix the crash and support inferring of asyncData return values.

The latter seems complicated and potentially risky (Vue types are a little brittle).

So IMO it's an option to just fix the crash without the support for inferring and I feel like this is much safer.

Not duplicating the asyncData properties in data has potential for breakage and in some cases different runtime behavior anyway. While in theory asyncData should always run first and set the properties on data, in practice we've seen crashes reported to Sentry when we forgot to duplicate those properties in data. This is potentially only an issue in very broken environments but still it can make a difference.

[rchl]

I did a bit more than minimal testing and it appears to work nicely in TS components.
Doesn't work in JS (+JSDoc when needed) components but that's fine because it's consistent with the current behavior.