modxcms/revolution — pull request #12092 by rtripault (2014-10-28 08:10:28+00:00)
Title: Composer

Note : this is mainly a PoC to be tested & reviewed

### What does it do ?

* removes dependencies from repository
* make use of Composer to handle dependencies (xPDO included) & some auto loading
* update dependencies (see composer.json)

Notes :

* xPDO is shipped with predis as well as [Garry's PR](https://github.com/modxcms/xpdo/pull/40)
* Composer requires PHP >= 5.3.2

### What to expect from this ?

1. breakage (hence why some testing is needed)
2. everything **must** work as before (if not, please comment with as much details as possible to help debug/fix, thanks!)

### How to install ?

pull, (make sure you have composer installed) composer install --no-dev, run setup as you would normally do.

I encountered an issue with Smarty dependency :
`Could not scan for classes inside "path/to/core/vendor/smarty/smarty/distribution/libs/Smarty.class.php" which does not appear to be a file nor a folder`

To manually fix, head over to `vendor/composer/installed.json`, search for

"classmap": [
"distribution/libs/Smarty.class.php",
"distribution/libs/SmartyBC.class.php",
"distribution/libs/sysplugins/smarty_security.php"
]

replace with

"classmap": [
"libs/Smarty.class.php",
"libs/SmartyBC.class.php",
"libs/sysplugins/smarty_security.php"
]

run `composer install --no-dev` again.

If you plan to try this on an existing installation, make sure to wipe your `core/cache` folder (encountered some issues with cached Smarty templates)

### What needs to be done/tested ?

- [x] make the setup process work
- [ ] test with old components (non class based processors/controllers)
- [ ] performances benchmarks ?
- [ ] S3 Media Sources (SDK has been upgraded an no bucket to test here)
- [ ] Revolution upgrade
- [ ] triple check Smarty templates, Smarty upgrade seems to introduce lots of exceptions (mostly due to templates trying to access undefined variables) when error_reporting(E_ALL)

### What needs to be done if merge is considered ?

- [ ] handle cases where `core` or `manager` folder are moved (would impact the setup process -- to find the auto loader), currently, editing `composer.json` & running `composer dumpautoload` is required
- [ ] think about future & potential usage of PHP namespaces
- [ ] think how third party components could define dependencies (how to handle "conflicts" ?)
- [ ] find a BC way to move 1 class per file (ie. no multiple classes definitions in a single file)
- [ ] update xPDO to make use of the loader too (no more "require_once")
- [ ] document how to make use of the loader for developers (ie. register classes/namespaces)
- [ ] move composer.json within `core` folder to become available/editable for developers (how will we handle upgrades ?)
- [ ] "[post composer](https://getcomposer.org/doc/articles/scripts.md)" script to clean unnecessary libs stuff (ie. tests, docs) to build a lighter Revo package
- [x] remove "unnecessary" files (dependencies now stored in `vendor` folder)

### What needs special attention/review ?

* `modManagerResponse::loadControllerClass` has been modified to handle duplicate class names for manager controller

### Making use of the auto loader

(in progress)

`Composer\Autoload\ClassLoader` is available in `modX->loader`

#### Making use of `composer.json` (global dependency)

Just edit `composer.json`, add your dependencies & run `composer update`.

PROS :

* libraries are shared across all components
* libraries are available anywhere `modX` is

CONS :

(mostly for components developers)

* manual steps required to install dependencies
* potential problem if different versions of a library is required (ie. libx-1.0.0 required by component-x & libx-2.0.0 required by component-y)

#### Shipping dependencies in third party components

You could use composer on handle dependencies on a component basis (each component would ship its vendor folder)

In service classes : `$this->loader->addPsr4('Vendor\\Namespace\\', '/path/to/namespace/')`