Build: composer dependencies added to production build

[jeherve]

This has come up in the past (see #13497 and #16399), and we had fixed it with #14900, by removing dependencies from the production composer.json when those dependencies were in fact shipped with the plugin, inside the vendor dir of Jetpack.

Unfortunately, we've lost that fix with the monorepo reorganization:
https://github.com/Automattic/jetpack-production/blob/9.4/composer.json#L14

@anomiex had mentioned that we could try Composer's provide property, see if it could solve our problem:
https://getcomposer.org/doc/04-schema.md#provide

Let's see if that can work for us, instead of having to edit composer.json during the build process.

[LeoColomb]

Arf, I was about to add an update on my original issue you mentioned #13497, I can't deploy anymore (again)... 😅

@jeherve Indeed, the provide property is probably better, but I would advocate for the replace, much better and still very simple to achieve.
https://getcomposer.org/doc/04-schema.md#replace

That said, whichever the solution chosen, I'm believe the conflict between a composer installation and its non-standard usage in Jetpack will continue to raise issues.
The root cause is technically still the same: calling to WordPress fonctions (add_action()) at Composer loading without delegating them to the Jetpack loader (where the WordPress environment is validated before).
Usually this issue is a non-issue with class loading/reflection and a standard method call.
It's already used for some Jetpack packages, maybe we can continue this?

[jeherve]

The root cause is technically still the same: calling to WordPress fonctions (add_action()) at Composer loading without delegating them to the Jetpack loader (where the WordPress environment is validated before).

Indeed. The compat package is where this happens.

The package was useful to maintain back compatibility when Jetpack first switched to autoloading, but at this point it may be interesting to consider not using that package, as most third-party plugins have now moved away from the legacy classes and functions used in the compat package (JetpackTracking, Jetpack_Sync_Actions, Jetpack_Sync_Modules, Jetpack_Sync_Settings, Jetpack_Client, jetpack_tracks_get_identity, and jetpack_tracks_record_event). A quick search in the repo reveals that no currently maintained plugin seems to use those without checking if they exist first. It may be safe to remove the package now.

Internal reference: p9dueE-1gA-p2

---

Still, even if we got rid of the compat package, it may still be worth considering using provide or replace, to avoid any future issues.

[LeoColomb]

It may be safe to remove the package now.

👍

The compat package is where this happens

Also here:

jetpack/projects/packages/backup/actions.php

Line 13 in 78eabe8

add_action( 'jetpack_backup_cleanup_helper_scripts', array( 'Automattic\\Jetpack\\Backup\\Helper_Script_Manager', 'cleanup_expired_helper_scripts' ) );

[LeoColomb]

@jeherve I'd love to help on this, but I need to know how do you prefer to manage add_action call in backup package before opening a pull request. Let me know 🙂

[jeherve]

I need to know how do you prefer to manage add_action call in backup package before opening a pull request.

I think it may make sense to rely on Composer's provide or replace, to be future-proof with any other packages in the future.

[LeoColomb]

@jeherve I've done some hard research about provide and replace usage, and:

• provide is too soft: require always take precedence, then it still have to be remove before committing vendor files.
• replace is too strong: packages listed in replace are not installed even if they are listed in require, then replace can only be added before committing vendor files.

replace seems a bit more accurate according to the schema, but again, both options are quite short-term workarounds.

The script to publish package to their own repo is very (very very) complicated, where the change have to be written?

[anomiex]

I agree that replace seems more accurate according to the schema.

You'll want to insert your new code for munging composer.json in build-all-projects.sh, probably at line 148 or maybe line 142. $BUILD_DIR points to the directory holding the files that will be committed to the mirror repo.