Clean Application Deployment Using Composer

Question

I started using Composer for a new PHP application (it uses several frameworks and APIs such as Laravel, Smarty, etc.), and everything is fine with it in development.

However, I'm not too sure how to start deploying this on a real production server. The subcategories of the corresponding modules in the /vendor directory seem to include a lot of materials that I would not normally include in the application (for example, demo files, installation files, documentation, etc.). Is this normal, or did the creators of these packages misunderstand how to create a Composer package?

Is there a standard approach for creating a clean deployment of applications that includes only the necessary distribution files, and not everything else that is not connected and should not even be there (even for security reasons)?

I ask a question about the most common workflow, or perhaps a specific command or configuration in composer.json that I have to look at in order to achieve this.

Answer 1

There are two recommendations that I would make that cover most of your worries.

1)

Use the composer update --no-dev to cut any development dependencies from your lock file only. Or change your requirements in composer.json to achieve the same.

Theoretically, package developers should support a clean production version (for example, not including all phpunit tests). However, yes, it’s pretty normal to have a lot of cool in the vendor library, mainly because the build concept is relatively unusual in PHP, so the “sources” and the “targets” are mixed.

Demos and readme are still an integral part of the "distribution" version of the component, so they will still be present if you specify no-dev, and it is just "I am not developing this package, I am just consuming it."

It seems like there is no composite feature: one level above this, which really is a super-clean package with minimal deployment.

2)

Keep your vendor's library above the root of the website.

This prevents unwanted browsing in the supplier’s library and eliminates any security issues with site visitors studying your libraries (if this is rightfully bothering you).

eg. I usually use

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

Where www is the web root of the virtual host. All entry-level scripts are located in your root directory as usual, and the path to autoload in ../vendor/autoload.php

Or, of course, www / might be the laravel root folder if you use Laravel for your site as well as api.

api can host a separate vhost for your laravel APIs if they run separately from the flat website.

(I save other folders above the web root of build , docs , src for SASS, JS, Grunt, etc., etc can safely store any configs, passwords, keys, etc.).

3)

If you are still unhappy with the luggage, then, as another commentator suggests, you want to look at the assembly process that cleans things up. It can become complicated and hard to maintain!

eg. you can create a local folder for www deployment (for example, updating the composer, as well as any grunt tasks, installing bower, publishing laravel / artisan, etc.) and then trimming it (custom scripts that you need to design) and transfer it's in a separate repository representing the published, flattened deployment target. This is what you would like to place on your website.

It should be automated or you will stop doing it, if after that a third time :)

But ... you have to ask why else do you want to crop provider libraries. Disk space? They are not so big. General cleanliness? Consider folders as black boxes and just read the API docs. those. don't look :)