Packages Manager

Plugins Discontinued
30

Hi. For the record I made https://github.com/fvsch/kirby-composerkit which kinda looks like an alternative to your first 3 steps. Though it’s a bit opinionated (it keeps Kirby core and the Panel’s PHP code in vendor).

I’m not sure there’s a point in extending the Kirby CLI with complexity to parse composer.json, resolve version requirements like Composer does, and install a series of plugins. If you’re going to use Composer, I’d go with a solution that relies on Composer only, not a combination of that + more steps using the Kirby CLI.

You can define any public git repo as a Composer package, though it’s a bit verbose, as defined in How to use Composer to install Kirby, Toolkit, Panel (note that this technique is not needed anymore for Kirby itself). For instance:

{
  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "distantnative/multiselect",
        "version": "master",
        "source": {
          "type": "git",
          "url": "https://github.com/distantnative/multiselect.git",
          "reference": "master"
        }
      }
    }
  ]
}

But if a plugin is only published on GitHub and not also available on Packagist, I would worry a little bit about its availability over time, and instead I’d install the plugin (manually or with the Kirby CLI) and I’d commit the installed files (rather than ignore them). I don’t want to create a project that can be installed now but not in 18 months when a developer changed their GitHub handle or deleted or renamed a repository.

1 Like