[WIP] Plugin management Composer support

[jaxwilko]

This is very much a WIP, the idea is to fully support plugin management via Composer.

So far I've added the usage to plugin:list, see:

Notice: you'll need to manually install winter/packager as I've not commit my composer.json as it's a mess

TODO:

• Add better support for package detection which isn't super slow, see: https://github.com/wintercms/winter/pull/967/files#diff-cb5276616360a228a987825e5c85cd0b545d8be4eca49a9f4bf534d413bb7987R131
• Formalise a internal format for composer packages, i.e. an object consumed by a plugin during registration which can be used by the rest of the system.
• Speed improvements, without caching it's currently taking ~10s per page load due to having to manually scrape package types and run multiple show commands.
• Add support for displaying when a package has a upgrade that can be performed.
• Either merge or properly handle the \System\Classes\Packager\Composer as it's currently just overriding the Composer class provided by winter/packager.
• Add support for the following commands
  • PluginInstall
  • PluginRefresh
  • PluginRemove
  • PluginRollback
  • PluginList

[bennothommo]

@jaxwilko re:

Speed improvements, without caching it's currently taking ~10s per page load due to having to manually scrape package types and run multiple show commands.

I'm wanting to actually implement this in Packager itself. I put in the ground work for a cache system that'll store package details as they are retrieved from the commands, but ultimately, I think in most cases we'll probably have to scrape the Packagist API directly instead of relying on composer show.

[bennothommo]

Also, might be worth adding those new commands into Packager as well. :)

[jaxwilko]

@bennothommo yeah I added support for some extra features that i'd like to merge in if they'd be useful for others, sorry for overloading like half of winter/packager btw, it was just easier for prototyping 😂.

As for speed and package caching, i ended up writing a composer plugin to do it for us: https://github.com/jaxwilko/composer-winter-plugin the advantage it gives us is that if the user runs either a winter command or a composer command, composer will update the package cache which then lets us detect which plugins come from what packages.

The speed issues for show then aren't massively important as we don't need to know them on cold starts and only for info in the backend which should be acceptable :)

[bennothommo]

@jaxwilko All good, I figured as much - still would be good to try and put it all in place in Packager once it's finished though.

With the Composer plugin, you could probably add your stuff to this repo too: https://github.com/wintercms/package-control. That was the Composer plugin that's going to act as a marketplace gatekeeper.

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in this pull request for the last 6 months.
If you intend to continue working on this pull request, please respond within 3 days.
If this pull request is critical for your business, please reach out to us at wintercms@luketowers.ca.

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in this pull request for the last 6 months.
If you intend to continue working on this pull request, please respond within 3 days.
If this pull request is critical for your business, please reach out to us at wintercms@luketowers.ca.

[LukeTowers]

Replaced by #1259