Amp-wp: Publish on Packagist

[swissspidy]

Looks like the Human Made folks have forked this repository in order to make it easier for them to use it with Composer. For this, they have published it on Packagist:

https://github.com/humanmade/amp-wp
https://packagist.org/packages/humanmade/amp

They don't want to rely on a third-party repository like WordPress Packagist to get their dependencies. Plus, since that site only mirrors the WordPress.org repository, you won't get pre-release version through it.

To make lives of developers and agencies using Composer easier, we could publish the plugin on Packagist ourselves.

Doing so is pretty straightforward, and requires no code change whatsoever. In fact, all that's needed is hitting a button on https://packagist.org/packages/submit. Since we already use GitHub releases to share the built ZIP files, Composer will automatically pick these up when downloading packages. So people will always get the proper version.

[roborourke]

@swissspidy thanks for this, although it's not so straightforward unfortunately:

1. I had to modify the build required check
2. You'll need to build the non composer deps or packaged releases won't work

In the above link you'll also see I added a CircleCI integration to build front end assets and push tagged releases. I'm not 100% sure how easy it'll be to convert to work with Travis but happy to try and help there.

[swissspidy]

Thanks @roborourke, that's a good point.

I guess we would need to upload two versions per release then: one fully built, and one only with the JS built.

Having Travis CI do the builds is also something I've been looking into (see #1840).

[roborourke]

My diff link was getting mangled - fixed now!

[westonruter]

I'm sure you're aware, but there are also *-built tags like 1.2-RC1-built which are just Git-committed version of the files in a build. This is suitable for Git submodules, and perhaps useful for Composer installation as well.

[swissspidy]

For a proper Composer project that's not of much help I think.

If a project requires packages A and B, and both packages require the same dependency, e.g. PHP CSS Parser, the dependency would be downloaded _once_ into the project's vendor folder and not two times within each package. That's a bit different when comparing to npm.
The *-built tags do not allow for this, because the Composer dependencies have already been resolved there.
But for a Composer project this should not be the package's concern. But because Composer does not deal with any JavaScript build step whatsoever, we'd still need to perform that step.

Certainly, #1867 would somewhat work around this, but in a project that only uses Composer that would result in unnecessarily duplicated code.

I have to admit that manually adjusting the workflow two have two different build files would be a bit of a maintenance burden for us. I'll see if I can have another look at #1840 to automate all of this.

In the long run, this would also help for #2315, because a Composer project could include this plugin as a dependency, but also some other package that requires the same shared AMP PHP library.

[swissspidy]

One thing that needs to be kept in mind with Composer: we are currently using cweagans/composer-patches to patch PHP CSS Parser. We'd need to ensure that this still works when pulling in the plugin as a Composer package.

[swissspidy]

@roborourke Haven't tested them yet, but here are two packages I just generated, one for use with composer, one standalone:

amp.zip
composer.zip

[westonruter]

Relates to #4215.

[mahnunchik]

Any news?

[westonruter]

@schlessera and @pierlon have started digging into this due to #5609, where the upgrade to Composer v2 started to break site(s) that are assembled with Composer.