Proposals (Political/Workflow) #4782

Officially support using Composer (instead of submodules) to start a new app

Added by Andrew Coulton over 1 year ago. Updated 6 months ago.

Status:NewStart date:08/26/2013
Priority:NormalDue date:
Assignee:Lorenzo Pisani% Done:


Target version:-


Following #4776 the official packages are all (as of 3.3.1) registered as composer packages on packagist. In that discussion, Zeelot said:

Should we do anything to support creating a new project with composer? Do we need to add something to the composer.json file in kohana/kohana

We should look into being able to start a kohana app from composer directly in the future :)

I think this makes sense, but as it stands the composer.json would conflict with the submodules in kohana/kohana. There are a couple of options I can think of:

Remove submodules from kohana/kohana and use composer exclusively


  • composer install (can be) faster, more straightforward and easier to keep up to date.
  • it's relatively easy to configure so that you always get either the corresponding stable packages for a release or the most recent dev packages if you want them - no more need to update submodule refs all the time


  • no longer possible to explore the whole source (kohana/kohana + the official modules and system) on github - so not as easy to get an immediate view of the whole framework, or to dig around on web to find where things come from (does anyone else do that?)
  • may mean a little bit of learning for people used to (and using) submodules
  • would lose a bit of change tracking by not having direct submodule refs and links - though could be resolved in other ways.
  • might need to review build and CI setup - although it would anyway be better and possible to have each package built separately rather than only in kohana/kohana

Stick with submodules, provide a sample composer.json and instructions on how to use it


  • no real changes to existing project workflow, etc


  • new users can't just grab the official application and run `composer install`
  • limits options for adding/recommending other external packages in future
  • doesn't move us forwards a great deal

Maintain separate composer and submodule based base apps

Probably the worst of both worlds - although because the composer version wouldn't need to always be updated to track module revisions it wouldn't take too much work to do...

Any thoughts?


#1 Updated by Sam Wilson over 1 year ago

I think using composer for modules is a great idea.

The extra learning of using composer over submodules is probably a small problem: I reckon there're probably more people struggling with submodules than with composer!

Does core fit into this as well? I mean, do you envisage the system directory also be a composer dependency? It wouldn't be of type kohana-module I guess...


#2 Updated by Andrew Coulton over 1 year ago

Yep, I'd envisage using composer for all of it (that's how we're starting to do it in our projects now). As of 3.3.1 core will have a composer.json but as a standard library package (so it would go in vendor/kohana/core).

I don't think that's a major issue, but it should be easy enough to add a kohana-system package type to the composer/installers project if people really wanted to have it installed to system like it is at the moment.

#3 Updated by Sam Wilson over 1 year ago


I've been installing kohana/core to MODPATH for ages anyway, so I think it'd be fine that way.

Thanks for working on all this stuff, by the way. :)

#4 Updated by Maxim Kerstens about 1 year ago

why not create a new repo called kohana/app similar to ?

Kohana would be installed (currently) as 'composer create-project happydemon/kohana-composer-bootstrap'

wouldn't there be a way to simply copy kohana/kohana without the system folder and the submodules during a build or something?

#5 Updated by Lorenzo Pisani about 1 year ago

I think I would like to switch to using composer and eliminate submodules. We could do the separate repo and deprecate kohana/kohana for a while and then archive it (stop making new version branches).

#6 Updated by Andrew Coulton about 1 year ago

I think switching entirely to composer is emerging as the best solution. I don't know if we need a new repo, couldn't this (create the composer.json and delete the submodules) happen in eg the 3.4 branch in kohana/kohana? Although I guess a repo called kohana/sample-app or similar has the benefit of being clearer about what it is.

I think if we're doing that it would also make sense to submit a patch to composer/installers so that kohana-module packages are by default installed in vendor/ along with any other third-party dependencies. This would however break existing projects, unless there's a way in the installer to detect that and still use modules/. The alternative is to change the composer.json in the core kohana-module packages to be just normal libraries but that would again result in them being installed to a different path in existing projects (though only following an explicit upgrade by the user) and loses some semantic value and future potential. I could take a look at how hard it would be to update the kohana-module installer?

#7 Updated by Guillaume Poirier-Morency 6 months ago

Moving to composer is a nice idea. This will allow Kohana modules to define a wide range of dependencies.

Although, I think that modules designed specifically for Kohana should end in modules and external libraries in application/vendor. This makes a clear dinsinction between what gets autoloaded by the CFS and what gets loaded by composer. Technically, we add "vendor-dir": "application/vendor" in "config" in composer.json.

Then, only add a line after the modules loading in bootstrap.php

// Autoloading composer packages
require Kohana::find_file('vendor', 'autoload');

This is pretty much what I do right now. This doesn't break anything and allow a full access to composer.

Also available in: Atom PDF