Composer docs/bugs (clarification)

(I’m using buildpack 4.3.77)

I’m trying to overcome a couple challenges deploying a PHP application to a CF PaaS (PWS).

I find your use of composer and related docs a little confusing:

By default, the PHP buildpack uses the composer.json and composer.lock files that reside inside the root directory, or in the directory specified as WEBDIR in your options.json. If you have composer files inside your app, but not in the default directories, use a COMPOSER_PATH environment variable for your app to specify this custom location, relative to the app root directory. Note that the composer.json and composer.lock files must be in the same directory.

COMPOSER_PATH is not mentioned in the table before. It would be great to get more detail if this is a leftover from another time or e.g. if this a separate var to point the buildpack to, to store composer.json (and .lock).

---

Also, is there history available what this means: “if you have composer files inside your app”.

I am confused by this statement, because — where else would they be? Composer keeps dependencies local to the application (usually). So this means, vendor/ should be within the application, not somewhere else.

---

What is the reason for default lib/vendor/ with this buildpack? Most code seems to expect vendor/? Most projects/frameworks follow a pattern where:

lib/ (sometimes called src/)
public/ (or web/ or www/)
vendor/

I realise there are (still) exceptions to this and people still put all their code in a “public” directory, but working around it like this, defeats the purpose of the buildpack to e.g. run a demo application.

---

I tried to use COMPOSER_INSTALL_OPTIONS:

{
    "COMPOSER_INSTALL_OPTIONS": "--no-interaction --no-progress",
    "COMPOSER_VENDOR_DIR": "vendor",
    "WEBDIR": "public"
}

This led to:

Invalid argument - - n o - i n t e r a c t i o n - - n o - p r o g r e s s. Use "composer require - - n o - i n t e r a c t i o n - - n o - p r o g r e s s" instead to add packages to your composer.json.

(Edit: I guess this should be a list.)

---

Maybe not in scope of this buildpack — is there a validator for everything in .bp-config/options.json)? E.g. pre-push, so I don’t have to dig around in the buildpack’s code to figure this out?

---

Happy to send a PR with doc fixes or discuss further.

[till]

@dmikusa-pivotal So I “pack” my app, add to Dockerhub and then change my manifest to use the docker image? I’ll see if I can try that on the weekend.

[till]

Long story short, the buildpack isn’t trying to force one way or another, just be flexible to support the different ways people want to structure their projects.

The Buildpack does the opposite right now though. It’s not turn-key, as it requires configuration for the majority of all PHP frameworks and demo applications. Best practice is not to rely on include_path anymore as composer encourages local dependencies (scoped within the app) and provides optimised autoloaders which…

1. Take care of finding files (by using mostly absolute paths, unless you tell it not to)
2. Provide optimisations for classloading with for OpCache (or formerly APC) and general disk I/O.

Examples (which expect $APPROOT/vendor):

• https://github.com/symfony/demo
• http://www.slimframework.com
• https://github.com/Laravel-Backpack/Demo

Search for more on Github — they all have (/)vendor in .gitignore.

If you follow a pattern where you have scripts in a bin/ folder, then most of these don’t work out of the box, as they ../vendor/autoload.php. That’s why most Symfony examples for Cloud Foundry disable/customize post-install-cmd. Not because the scripts don’t work, but because their invocation is broken by default (and I just happen to spend more time on trying to figure it out).

It’s great that the bp allows flexibility (even if I don’t see any merit), but this is using the opposite of what you should be the standard by introducing this lib/vendor thing.