Can repro by rolling back repos by 1 day using Arch Linux Archive.

However, "code" does seem to install fine from a fresh start. This may be a workaround i.e. remove code, electron, etc. Reinstall. But obviously it would be better if it "just worked".

10:45 gromit | :: installing electron (25.1.1-2) breaks dependency 'electron22' required by code
10:51 alerque | gromit: Being discussed in TU right now. This has been the status-quo upgrade breakage for a long time with electron, we're discussing ways to fix it. I'm working on a demo to verify or disprove the suggestion(s) for changing it.
10:51 | In the mean time manually install electron22, then Syu as usual.

> In the mean time manually install electron22, then Syu as usual.

This! Thanks guys.

$ sudo pacman -S electron22
resolving dependencies...
looking for conflicting packages...
:: electron22 and electron are in conflict. Remove electron? [y/N] y

Packages (2) electron-22.3.13-1 [removal] electron22-22.3.13-2

I went about it this way, as it refused to let me install `electron22` even:

$ sudo pacman --remove --nodeps --nodeps electron
$ sudo pacman --sync --asdeps electron22

This helped me solved the issue:
https://bbs.archlinux.org/viewtopic.php?id=278618

I don't think this is an issue with the `code` package, but rather with how electron versions are branched into a different package when a new major version is released.

This issue happens when the specified electron dependency ("electron22" in code's current version) is an alias to "electron" (as in "electron" provides "electron22") but later on "electron" is upgraded to a new major version and a new concrete package "electron22" is added to the repos.

I am not aware of a way to avoid this issue other than changing how electron itself is packaged.

A solution could also be to make pacman itself smarter, so that it is aware that an upgrade to "electron" breaks a dependency for "code" (this is already the case), but that a new package "electron22" can satisfy that dependency and by upgrading both at the same time there is no real conflict.

This is solved for me with the latest electron version, which has just landed in [extra]!

Caleb bumped code's pkgrel to force pacman to re-resolve its dependencies. That's a good workaround.

I guess upgrading electron should be done with a rebuild of all its dependents in the future.

This broken upgrade process where all dependencies had to be rebuild just to trigger pacman to reconsider updates has been the status quo for a long time. The shortcoming in pacman is being looked into, anthraxx is working on an issue.

In the mean time we've pkgrel bumped all the dependencies so you don't have to manually install electron22. We've also switched `electron` to be a meta package. This will resolve the issue the next time around for Electron updates, at the expense of a side effect: as apps get updated and eventually nothing depends on old versions of Electron they will end up as orphans or you system. The status quo was having to manually install then to satisfy deps (as in this bug report) AND remove them later when eventually unused. Now just the later issue remains, just slightly expanded from the cases where it will need manual installation.

Eventually when pacman handles this properly we'll switch to virtual provides with a runtime level.