Update Angular to fix security issues

[hansegucker]

PR Checklist

Please make sure to fulfil the following conditions before marking this PR ready for review:

• If this PR adds or changes features or fixes bugs, this has been added to the changelog
• If this PR adds new actions or other ways to alter the state, test scenarios have been added.
• I have the right to license the code submitted with this Pull Request under the mentioned license in the file LICENSE-README.md (i.e., this is my
  own code or code licensed under a license compatible to AGPL v3.0 or later, for exceptions look into LICENSE-README.md) and
  hereby license the code in this Pull Request under it.
  I certify that by signing off my commits (see In case of using third party code, I have given appropriate credit.
  We are using DCO for that, see here for more information.
• If I have used third party code and I mentioned it in the code, I also updated the inspired-by-or-copied-from-list.html list to include the links.

[lukasrad02]

Something weird is happening with the peer dependencies: In 66fcfaa (the most recent Angular update before this one), the "peer": true entries got removed on several packages in the lockfile. This time, they're all added again on the same packages.

I did the update in the aforementioned commit by running ng update @angular/core@19 and re-formatting the package*.json afterwards. Did you do anything else or in addition for this PR?

[hansegucker]

Something weird is happening with the peer dependencies: In 66fcfaa (the most recent Angular update before this one), the "peer": true entries got removed on several packages in the lockfile. This time, they're all added again on the same packages.

I did the update in the aforementioned commit by running ng update @angular/core@19 and re-formatting the package*.json afterwards. Did you do anything else or in addition for this PR?

That's the exact same thing I did.

[lukasrad02]

Hm…

I just checked npm explain @babel/core (which is one of the packages in question) and it is required by multiple different packages, sometimes as a peer, sometimes direct. Hence, I would just assume that npm does its magic here to determine whether the dependency should be listed as a peer or not and ignore the changes

[lukasrad02]

Disregard my previous comment, something is wrong here. Running npm run install:all on your branch changes the lockfiles on my system, removing the peer specifications again. Does this also happen when you do this?

Edit: I also get changes in the lockfiles of the other directories. Don't know yet why this happens…

[hansegucker]

Disregard my previous comment, something is wrong here. Running npm run install:all on your branch changes the lockfiles on my system, removing the peer specifications again. Does this also happen when you do this?

Edit: I also get changes in the lockfiles of the other directories. Don't know yet why this happens…

No, I don't get the changes

[lukasrad02]

Most likely caused by a bug in npm, see npm/cli#8431.

I think we can ignore those differences for now, update all systems to npm@^11.6.3 at some point, and then update the lockfiles with a consistent state if necessary).

Give me a second to test the update locally, but I'd expect that we can merge this PR afterwards