Integration of Composer in the core

Composer is the de-facto package system for PHP. In the TNG branch, we are using it extensively, and it allows us to re-use basic code from other people, and integrate libraries with much less overhead than we have today.

Also, it would free us from the quite complex code around the autoloader. Not only the autoloader itself, but the code taking care of loading classes and registering classes for modules and such. Composer could be used to handle that.

I have done a proof of concept in removing the autoloader and replacing it with Composer, and that worked out allright.

I've also started work on listing modules using composer functionality in the admin screen. After that, it's performing actions on those modules : installing/uninstalling/updating.

I like this approach - adding the functionality and allowing module developers to begin the work to enable it and leverage it in their modules in advance. It will make the move to TNG much easier and smoother.

I agree, that was one of the mistakes we made in our previous approach to 2.0 : we were looking for a big bang approach.

This way, we can gradually introduce functionality and change without breaking too much at once

On the subject of the composer integration, I have a working proof of concept for the included libraries, but if we want to leverage this for our addons, this will need more work

• trigger a re-build of the composer autoloader for every module action
• this means integrating composer as a library
• re-write the detection of modules using composer instead of the way it is done now (folder-based)

Let's see where I get by the time we ship ImpressCMS 2.1

Sounds reasonable.

What would be the migration path? Would composer support be added as another library like IPF was, supporting both types of modules?

The final goal should be that every dependency is managed by composer, in the vendor folder structure. If you do that, composer can manage the entire lifecycle, managing versions and also dependencies.

At that stage, we could also remove the code that supports our home-grows autoloader, which is a bonus in my view. It's quite complex code, and going for a standard approach will get that off our plates.

As a migration path, we could foresee some overlap during a few versions, and with a button that would allow you to upgrade to the composer-based version of your module. Given that creating a composer-based module (or translation, or theme, or other kind of addons) should not necessarily require code changes, it should be feasible to make that a smooth transition, just moving the module, while keeping the data intact.

It will take some adjustments to get used to the new mindset and I'm sure it will make more sense as we go through it.

Looking at the TNG branch, I see folders for modules, themes, libraries, and plugins, which makes it easier for me (and ICMS?) to differentiate between them. I also see a 'deprecated_class_aliases' package that appears to be the path for legacy modules and libraries, even the core itself as classes are moved to new locations.

My current objective is to familiarize myself with the composer architecture and methods while working on several modules that still need updates to be compatible with 2.0. These are modules I rely on heavily and have no viable substitutes. Good news is I'll be well-versed in these modules as the move to composer comes up.

The error we made in the TNG branch was to change too many things at once, and losing the overview. We did really cool stuff, but should have taken it more gradually.

For example : we tried to offload all the current install logic into the composer file. That was a huge mistake. The composer file became a monster of configurations, semi-code and workarounds. The end result was that no-one really understood what was going on in there, and we arrived with a solution that made things much more complex.

I think it would be a better approach to keep the composer file as simple as possible, and perhaps review the way modules are installed.

If we want to grow ImpressCMS again, simplicity should be the action word : make it simple for users and developers to work with ImpressCMS, otherwise they will be going to another CMS in a heartbeat. Plenty of fish in that sea.

Back to composer integration : the specific folders for modules, languages and themes could certainly be an option, BUT we shouldn't rely on the physical location of files to let ImpressCMS work. For example, instead of going through all the subfolders in the modules folder and looking for a version info file, the way it is done now, we should simply ask composer to return a list with all the installed libraries of type 'impresscms-module'. That way, the system keeps running, no matter where your files are stored.

What modules are the ones that you need working on 2.0? Let's see if we can work together on them to speed these things up a bit.