chore(deps): update vue monorepo to v2.7.8

[renovate[bot]]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
vue (source)	2.6.14 -> 2.7.10
vue-server-renderer (source)	2.6.14 -> 2.7.10
vue-template-compiler (source)	2.6.14 -> 2.7.10

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled due to failing status checks.

♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• [ ] If you want to rebase/retry this PR, click this checkbox. ⚠ Warning: custom changes will be lost.

---

This PR has been generated by Mend Renovate. View repository job log here.

[renovate[bot]]

⚠ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: frontend/package-lock.json

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: @vue/[email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/vue
npm ERR!   vue@"2.7.8" from the root project
npm ERR!   peer vue@"2.x || 3.x" from @sentry/[email protected]
npm ERR!   node_modules/@sentry/vue
npm ERR!     @sentry/vue@"7.8.0" from the root project
npm ERR!   10 more (@testing-library/vue, @tiptap/vue-2, ...)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer vue@">= 2.5 < 2.7" from @vue/[email protected]
npm ERR! node_modules/@vue/composition-api
npm ERR!   @vue/composition-api@"1.7.0" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/vue
npm ERR!   peer vue@">= 2.5 < 2.7" from @vue/[email protected]
npm ERR!   node_modules/@vue/composition-api
npm ERR!     @vue/composition-api@"1.7.0" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! See /tmp/renovate-cache/others/npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /tmp/renovate-cache/others/npm/_logs/2022-07-30T11_52_08_816Z-debug-0.log

[usu]

Tests and package compatibility is fixed. However, this currently breaks reactivity of hal-json-vuex objects. Needs further investigation.

Examples where reactivity breaks:

• Moving a ScheduleEntry in the picasso
• Adding the first StoryboardSection in a Storyboard

[carlobeltrame]

• Adding the first StoryboardSection in a Storyboard

By now, storyboards are always forced to have at least one section (because of our limitations with JSON patch I think) :) so this is no longer an issue directly.

• Moving a ScheduleEntry in the picasso

I was able to fix (or work around) that problem, by passing the whole scheduleEntries collection into the Picasso instead of just the items, and reloading that collection instead of the period's scheduleEntries. A subtle change, and I agree it should theoretically work both ways, but given that we want to re-write hal-json-vuex soon anyways.

I tried searching for other places where something similar could happen, but found nothing. DraggableContentNodes is the only place I found where collection items are passed into a sub-component which operates on a dirty-copy of these items, and drag-and-drop seems to work normally for me. Other places I found where items are passed to a sub-component are some dialogs, but these don't use auto-save.

So I propose if we don't find any more glaring bugs right now, we could merge this and fix any later findings later. This should hopefully enable us to replace vite-plugin-vue2 with @vitejs/plugin-vue2, upgrade to Vite 3 and more. So I think it would be worth it.

[usu]

So I propose if we don't find any more glaring bugs right now, we could merge this and fix any later findings later. This should hopefully enable us to replace vite-plugin-vue2 with @vitejs/plugin-vue2, upgrade to Vite 3 and more. So I think it would be worth it.

Sounds good to me. Didn't find any other bugs either. I think I found a similar solution once, but didn't follow it deeper as I assumed things are broken at more places. But doesn't seem that bad in the end. Did you figure out what exactly is the underlying issue? Or was this just the solution that worked in the end?

[carlobeltrame]

I just noticed that the Picasso component relied on an array of schedule entries being passed in, and then weirdly used this.period.scheduleEntries().$reload(), which the ScheduleEntries component never noticed. Did not debug any further, wouldn't really have known how to debug vue reactivity...