Publish the plugin in packagist

[ekandreas]

Is your feature request related to a problem? Please describe.
Please publish the plugin in packagist so that it is reachable with a standard composer based WordPress installation.

Describe the solution you'd like
Packagist publication

Describe alternatives you've considered
Manual git config

Additional context

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Changelog entry

Acceptance criteria

[swissspidy]

Just submitting the package is probably not enough, as it would need a dist version with built JS but without the bundled Composer packages.

[felixarntz]

Thanks for the issue!

We will explore that as an option. Once the stable release of the plugin is there, it will be available via wpackagist.org. For now, you can install it via Composer by providing something like this in your composer.json:

  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "google/google-site-kit",
        "version": "1.0.0-beta.1",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": "https://sitekit.withgoogle.com/service/download/google-site-kit.zip",
          "reference": "1.0.0-beta.1"
        }
      }
    }
  ]

[ekandreas]

It’s not a release without a dist, no.
And adding a repo endpoint to every package feels just so wrong when we all have packagist as default.

[archon810]

+1 for this, I was just about to submit it myself https://packagist.org/packages/submit?query=google%2Fsite-kit-wp and then found this ticket.

Why not just submit it there now, before it's fully released to stable, so that we can start using it without adding the github repo to our composer?

[swissspidy]

@archon810 As mentioned earlier in this thread, we cannot "just submit it there now", because the package would lack all the necessary built JavaScript and CSS assets.

Plus, the plugin would need to be tweaked to not include its own autoloader at all times:

site-kit-wp/includes/loader.php

Lines 17 to 18 in 13ca8a7

	// Autoload vendor files.
	require_once GOOGLESITEKIT_PLUGIN_DIR_PATH . 'vendor/autoload.php';

That's because with a Composer setup there is no vendor folder within the plugin's folder itself.

Essentially, it would mean that we basically have to maintain two versions of the plugin:

• One suitable for distribution via Packagist
• One fully packaged for release on WordPress.org

[ekandreas]

That is just not true.

[swissspidy]

@ekandreas Happy to be convinced otherwise :-) Can you perhaps elaborate on why that wouldn't be true? How do you intend to use this plugin using Composer?

To give some more context, we are currently in the same situation with the AMP plugin (ampproject/amp-wp#2649) and, according to a recent blog post, Yoast as well (https://developer.yoast.com/safely-using-php-dependencies-in-the-wordpress-ecosystem/)

[ekandreas]

Compile and check in the assets in the dist folder. Composer is taking care och the autoloading.
Take a look at Roots Bedrock, WordPlate or any other standard Composer based WP solutions.

[ekandreas]

Or just write that the assets needs to be compiled. It’s not a big thing to add it in the ci/cd-process.

[felixarntz]

Since the plugin has been released on wordpress.org a while ago, the recommended way to include it via Composer is via wpackagist.org where it is available as expected since it is sourced by wordpress.org.

Having a separate published version on packagist.org seems unnecessary, more so because it would require packaging built assets in that version (since just publishing the GH version would not work).

[yangm97]

Having worked at a marketing agency I feel like I should leave some feedback on this.

Fetching a plugin "natively" through composer implies dependencies are going to be consolidated at the vendor directory, which in turn reduces disk usage by duplication. At a glance it may not seem like much but it's honest work it scales pretty quickly as more plugins are added.

One could say the most duplicated asset between plugins is actually frontend frameworks such as bootstrap, and it's not wrong, but every byte counts when you're running wordpress severless.

Then one could also say this kind of setup is not that common, to which I reply: Well of course not! The wordpress community as a whole hasn't fully embraced composer as the defacto dependency management solution to this day. Of course there are bigger offenders on that regard such as Elementor Pro and countless proprietary plugin update systems not acknowledging the existence of composer but that's kind of offtopic.

The point is: We're stuck in a (bad) feedback loop. And no effort is too small to help us break away from that chain.

I just think it would be cool to keep this kind of issue open along with some instructions on what needs to be done to get it going, just in case somebody wants to contribute.

[felixarntz]

@yangm97 As I mentioned before, you can currently install the plugin with composer, using wpackagist (I'm actually using that on my personal site as well, which I manage with composer). Could you clarify what problem you see with that approach? What would be the benefit of having the plugin published separately on packagist?

[swissspidy]

@yangm97 As I mentioned before, you can currently install the plugin with composer, using wpackagist (I'm actually using that on my personal site as well, which I manage with composer). Could you clarify what problem you see with that approach? What would be the benefit of having the plugin published separately on packagist?

The issue with that is, when you load another package XYZ via Composer that also includes e.g. Guzzle, you end up with two versions of Guzzle in your project. Whereas ideally, in a normal Composer project, it would only be installed once and used by both packages.

[swissspidy]

You might want to read discussions at ampproject/amp-wp#5745 and ampproject/amp-wp#2649 for some context on why publishing a project like this to Packagist is not as straightforward as you might think

[felixarntz]

The issue with that is, when you load another package XYZ via Composer that also includes e.g. Guzzle, you end up with two versions of Guzzle in your project. Whereas ideally, in a normal Composer project, it would only be installed once and used by both packages.

That makes sense, in principle. However, by default Site Kit has all its production dependencies prefixed, so for those publishing on packagist wouldn't actually solve the problem. So if that's a crucial part of it, we'd need to cater for that, making this less trivial than just simply publishing it.

[swissspidy]

The issue with that is, when you load another package XYZ via Composer that also includes e.g. Guzzle, you end up with two versions of Guzzle in your project. Whereas ideally, in a normal Composer project, it would only be installed once and used by both packages.

That makes sense, in principle. However, by default Site Kit has all its production dependencies prefixed, so for those publishing on packagist wouldn't actually solve the problem. So if that's a crucial part of it, we'd need to cater for that, making this less trivial than just simply publishing it.

Just imagine not doing the prefixing all the dependencies just for Packagist... basically ending up maintaining two versions of the plugin. Doesn't sound very appealing to me.