Clean application deployment when using Composer

Question

I have started to use Composer for a new PHP application (it uses a few frameworks and APIs such as Laravel, Smarty etc.) and all is good with it in development.

However, I am not too sure about how do I go about deploying this on a live production server. The sub-directories of the respective modules under the /vendor directory seem to include a lot of stuff which I would not normally include with an app, (such as Demo files, installation readmes, documentation etc.). Is this normal, or is it that the creators of those packages got the wrong idea of how to create a Composer package?

Is there a standard approach to create a clean app deployment that only includes the necessary distribution files and not the rest of the stuff which is not related and should not even be there (even for security reasons)?

I am asking about the most common workflow used, or maybe a specific command or configuration in composer.json I should be looking at to achieve this.

Answer 1

There are two recommendations I'd make which cover most of your worries.

1)

Use composer update --no-dev to prune out any dependencies for development only from your lock file. Or tweak your requirements in composer.json to achieve the same.

In theory the package developers should keep the production version cleaner, (e.g. not including all the phpunit tests). However yes it's pretty normal to have a lot of 'cruft' in the vendor library, mostly because the concept of build is relatively uncommon in PHP, therefore "sources" and "targets" are intermingled.

Demos and readme's are still a necessary part of the 'distribution' version of a component so will still be there if you specify no-dev, which is just to say "I'm not developing this package, I'm just consuming it".

It does feel like there's a missing composer feature: one level above this which is indeed a super-clean deployment minified package.

2)

Keep your vendor library above the web root.

This prevents any unwanted browsing into the vendor library, and removes any security issues of site visitors exploring your libraries (if that's what you were rightfully worried about).

e.g. I typically use

domain
    /api
    /etc
    /vendor
    /www
        /js
        /css
        /images
        /index.php
        /foo
            /bar.php

Where www is the virtual-host web root. All entry-level scripts are in your web root as normal and path to the autoload at ../vendor/autoload.php

Or of course www/ could be the laravel root folder if you're using Laravel for your website as well as api.

api can host a separate vhost for your laravel APIs if they're done separately from a 'flat' website.

(I keep other folders above the web root build, docs, src for SASS, JS, Grunt etc, etc can securely store any config, passwords, keys etc.).

3)

If you're still not happy with the baggage, then as the other commenter suggests, you'd want to look at a build process which cleans things up. This can get complex though and difficult to maintain!

e.g. you could build to a local www deployment folder (i.e. composer update, plus any grunt tasks, bower installs, laravel/artisan publishing etc), then prune it back (custom scripts you'd have to engineer), and commit that into a separate repository representing a published, flattened deployment target. This is what you would deploy to your website.

This would have to be automated or you'd stop doing if after about the third time :)

But... you have to ask why else you'd want to prune back the vendor libs. Disk space? They're not that big. General tidiness? Consider the folders as black boxes and just read the API docs. i.e. don't look :)