Favorite mechanism for including plugins

Kirby 2 Questions 🤔
1

Hey there,
for quite some time, nice Kirby people approached me and asked if I could provide Composer support for my plugins, most recently for Kirby-WebP. This leads to Composer’s vendor folder residing inside my plugin folder, which obviously isn’t considered best practice.

While thinking about adding Composer for future Kirby versions, right now I’m more of a Git-oriented person - and since people downloading plugins from Github or adding them as submodules rely on the Composer-based stuff being already there (and I don’t want to force another dependency upon them), I wanted to know how you feel about this:

What’s your favorite way of including Kirby plugins?

  • Git
  • Composer
  • Kirby CLI
  • Just downloading it
  • Other
  • What?

0 voters

Show results

If you are going with ‘Other’, please tell me what it is - until then …

:sunny:

… have a good time
S1SYPHOS

PS: Hopefully, this isn’t a double-post, only thing comparable was this thread asking about deployment strategies. Git-oriented posts mentioned there can be found here and there.

2

On larger projects I tend to use git submodules. On smaller projects, I sometimes download them manually.

I don’t really have experience with Composer, but I’m feeling I should get started with this any time soon. Someone has a good starting point (not only the ‘technical’ stuff, but also pro and cons)?

3

My problem with submodules is that there is no semantic versioning support - if you update your submodules you get the latest master branch, no matter if it includes a breaking change or not.

I used to release the plugins i worked on via submodules and that is the main reason I switched.

Also if a submodules you use in your Projekt is updated (breaking changes) and a user installs it it might not work anymore and you have to fix your plugin.

The whole experience is unstable and can get really frustrating really fast.

4

Hi @Pascalmh, you can checkout whatever commit of your submodule you want to your repo? And the checked out submodule commit gets commited to the repo branch… Or am I mistaken?

5

Yes thats right, the update instructions make you checkout the master and then pull… Oh yeah, anther one was getting a submodule out of your project again…

6

I’m removing submodules on a daily basis, but you are right, that’s tedious sometimes :slight_smile:

7

And adding/removing submodules with multiple people on the same project on different servers (beta, staging, production) can make you go crazy pretty fast.

Another advantage is that with composer you do not have to set your dependencies to one commit hash but instead you just specify a version you want to use. I installed kirby via composer and I get all the fixes that are added to whoops in version 2.1 when updating my composer dependencies without the kirby team having to do anything.

1 Like
8

I’m doing it like you, if developing / maintaining a project over a longer period (that’s being paid for, I must say), then I’m going for submodules.