Update zetacomponents/mail to 1.9.3 so can remove patches

[demeritcowboy]

Overview

The patches that were being applied started failing today on drupal 9 since zeta just included them in 1.9.3.

The only other included change seems to be zetacomponents/Mail@606a075 but I don't think it changes anything.

require-dev has changed to require phpunit9, but I don't think that changes how it gets installed on the test nodes. Let's find out.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[seamuslee001]

@demeritcowboy should we put this against 5.53?

[demeritcowboy]

Yes good point.

[totten]

Strictly speaking... shouldn't the composer.json also be updated to ~1.9.3? I suppose it's not too big of a deal, but FWIW here are steps where it could to make a difference:

• (Last week) Install D9 + Civi 5.52.0 + zeta mail 1.9.2
• (Next week) Upgrade to 5.52.2. Note that this could be done a couple ways:
  1. Run composer upgrade (all, incl zetacomponents/mail)
  2. Run composer require civicrm/civicrm-{core,packages,drupal-8}:~5.52.2 (just Civi)

The first variant would incidentally upgrade zetacomponents/mail to 1.9.3 (new patches), but the second would leave the lock at 1.9.2 (but now without a list of patches).

Worst-case -- some deployments are missing 86.patch and 88.patch? Which isn't terrible, since these patches address uncommon scenarios (php81 and single-quote-emails) - and since you can recover with another composer upgrade. But it's worth considering with other patches.

[demeritcowboy]

Fair point. I've posted PRs.

Anecdotally, I've noticed when people use the require variation they automatically add -W, I suspect because the command so often fails and at the bottom of the error message it suggests doing that (rightly or wrongly), so after a while they just do it every time at the start. But that's just an anecdote and the above scenario is of course a real scenario.

[totten]

Oh, I'd never seen the -W option. That's a neat one.

[jensschuppe]

Are the patches actively being checked for still being applicable regularly (e.g. just before every CiviCRM Core release) with the latest version of the affected packages? If so, why not lock their version to this specific one so that composer update will not update them and potentially cause patches not being applicable and CiviCRM not working correctly? Of course, people will lose intermediate updates of those packages that do not interfere with the patches, but CiviCRM would then upgrade to this version with its next release, so it would just be delayed for a month at most.

[demeritcowboy]

I'd personally be fine with locking every package to a specific version, but then it raises the question of why even use composer, which I'd also be personally fine with getting rid of. But there's a more general discussion at https://lab.civicrm.org/dev/drupal/-/issues/164

[thomst]

Using composer or not is a big question. But this issue could be very easily fixed by setting those packages for which patches will be applied to a fixed version. Otherwise there is no guarantee that patches could be applied. And therefore the system might not work correctly as @jensschuppe said.