Release on Composer

[lukasbestle]

A little checklist of what we still need to do for proper Composer support:

Can be done now:

• [x] Create a .gitattributes file to exclude tests, scripts and config dotfiles from the ZIP export
• [x] Check in the dist folder to the repo (don't ignore it in .gitignore)
• [x] Add a basic composer.json to the Starterkit so that composer create-project works
  • Should include "optimize-autoloader": true by default
• [x] Delete the k-next/composer-repo repo (not needed anymore)
• [x] Enable Travis and Coveralls on the composer-installer repo
• [x] Update docs on:
  • Creating a new Kirby project with composer create-project getkirby/starterkit
  • Adding Kirby as a Composer dependency to an existing project
  • Updating Kirby using Composer
  • Installing and updating Kirby plugins using Composer

Needs to be done with the first public release:

• [x] Remove "minimum-stability" in all composer.json files
• [x] Require the installer from the composer.json of the kirby package (undo https://github.com/k-next/kirby/commit/efea0db6dfa1d1eea7f5289f5597029fdbe3d9e6)
• [ ] Publish the kirby package on Packagist
• [x] Publish the composer-installer package on Packagist
• [ ] Publish the starterkit package on Packagist
• [ ] Setup GitHub hooks for Packagist
• [ ] Create a public releases repo without source files but with vendor files and commit each release to it for use with a Git submodule installation
• [ ] Update the composer-installer repo link after launch

[bnomei]

my 2c

• remove minimum-requirement: "beta" from composer.json
• add composer.json data where possible. i think the support should be a quiet obvious choice.
• add "optimize-autoloader": true or something like a "kirby-update" composer script by default which does composer update; composer dumpautoload -o; see Autoloader Optimization
• maybe you have usecases for event-triggered skripts like displaying a changelog post update
• you could feature top10 plugins (counting stars) in the suggested data
• github webhook/app permissions for packagist to allow faster release propagation

[lukasbestle]

Thanks for your input, I have amended it to the first post.

add composer.json data where possible. i think the support should be a quiet obvious choice.

We already have the support key in our composer.json. However I think we shouldn't make the composer.json too complex because all of that needs to be maintained. So we are focussing on the fields that are most useful.

maybe you have usecases for event-triggered skripts like displaying a changelog post update

If every package did that, the Composer output would get very very confusing. Maybe later if we really have a use-case for such a script, but not just "because we can". :)

you could feature top10 plugins (counting stars) in the suggested data

Again we would need to maintain that and also it produces a lot of output to the Terminal. Let's keep it simple. Most important is that installation with Composer works and works reliably.

[bnomei]

@lukasbestle you are right. i did not think about terminal output and dependencies. simple is better.

[luxlogica]

Could I also kindly put a request for:

• updating docs on Composer-based installation (of all kits)
• updating docs on Composer-based updates
• adding docs on Composer-based plugin installation and updates (with an example that newbies can follow)

[bastianallgeier]

✅