I am sorry if this has been asked before but after searching for a while I couldn't really find answers to my dilemma.
I am part of team that is working on a PHP project and we use github for our version control. We would like to implement a PSR-4 autoloader and every single guide uses Composer so we would as well. Now, while searching I learned that the vendor folder should not be included into github, but only the composer.json and that every developer needs to install composer onto their own computer.
Does that require the autoloader to be created again on every developers computer.
And finally, when the project is done, we would like to upload it onto our website, but the only way we can do that is through FTP.
Which files should be uploaded to the live website and what would happen to th autoloader?
You need to commit the composer.lock file as well. That's super-important - it means that whenever someone else checks out the code they get the same set of dependencies (including their exact versions) installed to their /vendor directory.
That's why you don't need the /vendor directory to be committed - the lock file takes care of ensuring the dependencies are fixed.
The composer.json defines numerous potential versions of your dependencies that meet your requirements. Running composer update essentially checks to see if a more recent version is available that meets those requirements. That's the difference between install and update - install goes off the lock file and knows exactly what to look for - update goes off the json file and could return different results at different points in time.
In your composer.json you can define the autoloader by telling it where your root namespace lives.
"autoload": {
"psr-4": {
"RootNamespace\\": "library/src"
}
},
When your colleagues have run composer install it will create the autoloader for them in a consistent path.
You have options for deployment:
You can either upload the composer.lock file and run a composer install on production, or do it ahead of time and upload your vendor directory as part of the build.
I do the latter as I would prefer if there was an issue at this point to know about it before any files are changed on the production server. The alternative could leave a botched upgrade on production with missing dependencies. Safer to install those dependencies first and transfer everything in one go.
As an aside, I also like to install a fresh release to a separate folder on production named after the git commit and then symlink it as part of the deployment step. This ensures you don't have a half-updated application whilst you wait for the rest of the files to be uploaded. This approach would also eliminate the issue mentioned before, meaning you could do your composer install from production.
Related
I'm trying to install the Coinbase PHP API but it requires Composer:
https://github.com/coinbase/coinbase-php
I'm looking for a universal PHP solution (perhaps a function) to let me install composer packages directly onto my server, without having to use Composer.
I think the developers of Composer believe they are helping people, but actually there are thousands of beginner developers that are being locked out of learning web development by the 'Composer barrier'.
It would really help if there was a flexible solution or some approach where we could install without Composer? How can I do this?
Please don't respond with some sarcastic comment. There are people that don't want to use Composer and I don't see why we should be herded into a specific third-party software in order to do web development.
You can try https://php-download.com/ which can help you download all dependency most of the time along with vendor folder. It promises composer not required.
Tried it myself. It finds and creates all required folders and zips it for download. Works perfectly !!
The composer.json file lists the dependencies. In your example:
"require": {
"php": ">=5.5.0",
"guzzlehttp/guzzle": "^6.0",
"psr/http-message": "^1.0",
"psr/log": "^1.0"
},
You must then find the corresponding packages in the packagist site. Repeat the same process for each dependency: find additional dependencies in their corresponding composer.json files and search again.
When you finally have a complete list of the required packages, you only need to install them all one by one. For the most part, it's just a matter of dropping the files somewhere in your project directory. But you must also ensure that PHP can find the needed classes. Since you aren't using Composer's auto-loader, you need to add them to your own custom autoloader. You can figure out the information from the respective composer.json files, e.g.:
"autoload": {
"psr-4": { "Coinbase\\Wallet\\": "src/" }
},
If you don't use a class auto-loader you'll need to figure out the individual require_once statements. You'll probably need a lot of trial and error because most library authors won't care documenting that.
Also, and just in case there's confusion about this:
Composer has an official GUI installer for Windows and a copy and paste command-line installation procedure for all platforms.
Composer can be run locally and its output just uploaded elsewhere. You don't need SSH in your shared hosting.
The command needed to install a library can be copied and pasted from the package web site—even if the package maintainer didn't care to document it, packagist.org generates it by default.
Composer is not perfect and it doesn't suit all use cases but, when it comes to installing a library that relies on it, it's undoubtedly the best alternative and it's a fairly decent one.
I've checked other answers that came after mine. They mostly fall in two categories:
Install a library and write a custom download script with it
Use an online web based interface for Composer
Unless I'm missing something, none of them address the complaints expressed by the OP:
Learning curve
Use of third-party software
Possibility to develop right on the server (using SSH, I presume)
Potentially deep dependency tree
I'm using shared hosting for a website and can't execute commands there. Aside from running composer via php script request that I request via browser, I usually use this workflow:
Make sure you have php installed locally.
Make directory on desktop.
download composer.phar from https://getcomposer.org/download/ (under header *Manual Download) and place it in the directory.
make a file composer.json paste in it the following contents
{
"require": {
"coinbase/coinbase": "~2.0"
}
}
Browse to the directory with the shell of your choice(bash, git-bash, cmd, windows bash)
type php composer.phar update
Upload the vendor directory to your webserver via ftp or whatever mechanic you use.
include in your php project where you load your libraries(modify path to where you uploaded the vendor dir so it will include that autoload file)
require_once('vendor/autoload.php');
This way you get the benefit of dependency management and you don't have to include manually all the gazillion of files and download all the dependencies manually, and updating them is just as easy as typing php composer.phar update and then replacing the vendor dir on your server with the new one.
An alternative solution that worked for me (since php-download was down) can be done by making your own little local composer downloader.
Download and install XAMPP locally: https://www.apachefriends.org/index.html
Download and install composer locally: https://getcomposer.org/download/
Open commandprompt, navigate to say c:\temp and and simply type the composer dependancy, for example: composer require league/oauth2-client
Copy the files from your c:\temp folder to your web host using an FTP program
Add this to the top of your php: require("vendor/autoload.php");
This is not the ultimate solution but for me it was a big help for most of the cases:
https://github.com/Wilkins/composer-file-loader
Allow you to load composer.json file just as composer would do it.
This allow you to load composer.json file without composer (so
theorically PHP 5.2 is enough)
I know the question is old but I hope it will help someone.
I had to do this for an FTP server I didn't have SSH access to. The site listed in here worked, then I realized you can just do a composer install on your own server (using your target's PHP version), then copy all the files over.
Analizing the problem
The problem in installing the dependencies without Composer is the autoloading system.
Composer use a homemade autoloader based on an array map, this is a de-facto standard.
But this autoloading system, "fortunally" in this case, is not PSR-4 compliant.
PSR-4 is the de-iure standard for autoload a class in PHP, so you can't escape from autoloading. You must use one of them.
Solution Proposal
In this case, this brilliant PSR-4 autoloader is capable to be manually configured to autoload a VendorClass in a VendorNamespace anywhere in your code, as long as you require the custom autoload.php file early in your source code.
Real life example
Let's look at this example:
I have a legacy project who can't and won't use Composer never and never even if God allow this with a miracle. This project can be speed up in development with this fantastic package for command line scripts.
This is my project directory structure:
- src
- tests
- vendor (not the Composer's one)
This package has this directory structure:
- examples
- src
- Commando
- tests
The only thing I need is the src folder. Placing this folder in my vendor folder would be fine. So my custom autoloader would be like this:
// Constants
$base_path = "path\to\my\project";
$autoloader_class = '\vendor\MarcoConsiglio-Wichee\PSR-4-Autoloading\Psr4AutoloaderClass.php';
define("BASE_PATH", str_replace("\\", DIRECTORY_SEPARATOR, $base_path));
// Autoloader
require_once BASE_PATH.'\vendor\MarcoConsiglio-Wichee\PSR-4-Autoloading\Psr4AutoloaderClass.php';
// Init the autoloader.
$package = [
"nategood\commando" => [
"namespace" => "Commando",
"path" => str_replace("\\", DIRECTORY_SEPARATOR, '\vendor\nategood\commando\src\Commando')
],
"kevinlebrun\colors.php" => [
"namespace" => "Colors",
"path" => str_replace("\\", DIRECTORY_SEPARATOR, '\vendor\kevinlebrun\colors.php\src\Colors')
]
];
// Register namespaces.
$loader = new \PSR4\Psr4AutoloaderClass;
$loader->register();
// Namespace // Path to source
$loader->addNamespace($package["nategood\commando"]["namespace"], BASE_PATH.$package["nategood\commando"]["path"]);
$loader->addNamespace($package["nategood\commando"]["namespace"], BASE_PATH.$package["nategood\commando"]["path"]."\Util");
$loader->addNamespace($package["kevinlebrun\colors.php"]["namespace"], BASE_PATH.$package["kevinlebrun\colors.php"]["path"]);
Now I can use the command package anywhere in my project!
Pros & Cons
This solution allow you to:
Easely and manually build your own custom autoloader (you only need to specify the VendorNamespace and the folder(s) where search for VendorClasses in the VendorNamespace.
Freely organize your composer dependency anywhere in your project folder (and why not, outside it)
Import a composer package as is in your project (either downloading locally with Composer or cloning the package repository) or a relevant part of it (i.e removing composer.json file or files that require the composer autoloader).
Cons:
Manually build your custom autoloader means to work on every required dependency of your project (i hope not a lot).
Mistakes in package source paths can be tedious and frustrating.
Works only with PSR-4 compliant file names (i.e. can't use a A.class.php file name)
I followed instructions from an answer of a similar topic(https://stackoverflow.com/a/17531897/4388482). Well, my app is getting deployed on Heroku but it doesn't work good. I'm getting the following warning
Your project only contains an 'index.php', no 'composer.json'.
Using 'index.php' to declare app type as PHP is deprecated and may lead to unexpected behavior.
Do I need to install something maybe?
UPDATE
Project structure was initially this:
I did the following:
Installed PHP 5 and composer.
I renamed package.json to composer.json and removed package-lock.json.
Typed "composer update" command. I got "nothing to install or update" message.
Added vendor to gitignore. Pushed changes to heroku.
I got the following warnings
Your 'composer.lock' is out of date!
Composer vendor dir found in project!
The complaint that Heroku has is regarding this folder.
For the record, the contents of this folder presently are:
bootstrap
fontawesome-free
jquery-easing
jquery
What has happened here is that someone has committed dependencies to your version control, which is not good practice. It will work as is, but it is not very easy to do upgrades, especially since you cannot easily see what versions you currently do have.
There are three ways to go about this.
Decide if these are PHP dependencies, by searching Packagist. There is a Composer dependency for Bootstrap, but you would need to see if the version you are using is available (or whether you can upgrade to one that is available).
Decide if these are JavaScript dependencies, by searching NPM. I wonder if it is worth examining the contents of your package.json in case these are already covered. For what it is worth, I would generally consider these candidates for JavaScript libraries rather than PHP, but do what works for you.
Choose to leave these dependencies committed in the existing vendor folder. It will work, but it is not ideal for the reasons already stated.
In the last two cases, you could probably get away with a composer.json file thus, which you should commit to the repo:
{
"require": {
}
}
You could try a composer install after this, to see if it will generate a .lock file on an empty dependency list. If this does generate, then you should commit this also.
Bit of a strange set up but have come across a project where Composer has been used in a local environment to get a project started. The original developer did not have ssh access to the production server therefore he used Composer locally and uploaded the 'vendor' directory from his desktop to the server using FTP.
I now need to add the PHPMailer package so have done the following locally on my Mac:
cd Desktop/
composer require phpmailer/phpmailer
This has created the following structure on my desktop:
Desktop/composer.json
Desktop/composer.lock
Desktop/vendor/autoload.php
Desktop/vendor/composer/*
Desktop/vendor/phpmailer/*
Which of these do I need to upload through FTP? I realise vendor/phpmailer/* is the package I want, so will need uploading.
What about the others? I already have an autoloader configured so guessing vendor/autoload.php is not required here?
composer.json I could add the package to what's already there, e.g.
"require": {
*other packages here*
"phpmailer/phpmailer": "^5.2"
}
But I wasn't sure if that's necessary because I'm not going to be using ssh/Composer on the server to run any updates?
The usual workflow would be:
Checkout the current version from the version control.
Add dependencies via command line composer require new/package.
This will download the new package and update the autoloading.
Test the result locally or on a test website environment.
If happy with the result, upload the whole folder to the production server.
There may be several exceptions from this general workflow:
ad 1: If there is no version control, you'd probably better of starting a local git repo right now, and download the current production state into it as the first commit. Not having version control will make things harder, especially going back to known working versions. And because the files on the production server are probably unmanaged, you'd also check in the vendor folder into your newly created version control just to avoid canceling any changes that had been made to these files.
ad 2: Manually editing the composer.json file sometimes is a faster way to get what you want if you know what you are doing, but you'd have to correctly edit the JSON. For me it usually is too much hassle if I already have a command line ready. The command will also select a matching version that fits into the already installed dependencies. Manual editing may lead to version conflicts that you'd have to untangle. Remember to only install dependencies that work with the PHP version in production. You probably should run composer config platform.php X.Y.Z in order to add the production version of PHP into the composer.json file, which prevents Composer from installing dependency versions based on your development PHP. Adding the -g switch will add this setting to your global (user) setting instead, which will affect all composer operations you start, also for other projects.
ad 3: Manual editing will require you to run composer update on the command line, so there's probably no reason to not do composer require instead.
ad 4: How this could be done is entirely dependent on what environment you have to work with.
ad 5: At this stage you have assembled all files necessary to create a working website. Uploading them to production will always result in a working website unless the upload fails somehow. You could also use some "upload first to temporary folder, then move on the server" approach if you fear FTP would be unreliable. Some people take a different approach: They have a git repository on the production server and they simply push the version that should go live onto that remote repo. Some post-push scripts will run composer install then. This automated approach will also work (but not using FTP), but has the higher risk of something failing during deployment, and probably has no easy way back to the previous situation.
So in the end I'd say that uploading the whole folder structure via FTP (well, that protocol is insecure itself, better replace it with FTPS (FTP with SSL), SFTP or SCP) is better compared to running Composer on the production server.
Your specific question regarding which folders to upload: All of them. Especially upload the whole vendor folder. It contains the current autoloader and all dependency packages the software needs. If you worked correctly, you downloaded the existing composer.json and composer.lock file together with everything else and added the new dependency to it. This has changed both these files, added the new package to the vendor folder and the classes to the autoloader.
Don't fiddle with uploading only parts of the vendor folder, or manually editing a component of the autoloading. You will only create surprises for the developer coming after you if you do some aspect incorrectly, and it also takes more time. Composer is a very good tool to manage dependencies - use it!
You could copy the composer.json from the server to your local server, add the requirements and run composer update.
After that you can copy all files (composer.json, composer.lock and vendor folder to your server)...
Or you can copy local vendor/phpmailer into servers vendor folder, search for the entry of phpmailer in vendor/composer/autoload_psr4.php and add it to your servers vendor/composer/autoload_psr4.php.
Using this method also add phpmailers dependencies the same way.
composer depends phpmailer/phpmailer
I'm already half way done with a project in Symfony2.
I need to install a couple of new vendor bundles using composer.
I already have everything (minus logs, cache and parameters.yml) in version control (including the vendor folder).
Problem is when using composer update, it deletes the .svn folders in the vendor folders that where updated. So it's basically impossible to commit now (gives me not a working copy error).
Additional information: I'm working locally and committing to a dev server and then once approved an application server. Therefore it has to be perfect (cannot just run php composer install or php composer update on the dev/application server after commit).
I also tried exporting everything and copying and pasting them back into the repo but that also didn't work (index page broke locally).
Regarding to vendor versioning the best way is not version vendors at all.
The only things you need to version are composer.json and composer.lock. This may cause a problem with vendors which doesn't have stable versions or with that for which you need not stable one (eg. master with particular commit).
As a solution you should create your own (private) vendor repository (let's say your own packagist). Composer has a tool for that, which is called Satis.
https://github.com/composer/satis
So my suggestion would be:
Create a private repository with Satis. You place every package you need in satis.json and whenever you need to update a version of vendor, or add new one, you only modify satis.json and rebuild repository.
In your project's composer.json you set your new private repository as the only repository and set option: packagist to false.
Now, every time you run composer install it will use only your private repository, so it's fast and you always sure that every environemnt has the same versions
-
I was in similar situation two years ago.
The hard lesson I learned was never to edit files within vendor. At first I totally rejected using composer and manually cloned everything I needed. Later on, I decided to fork projects I needed to edit and referenced my forks instead.
Composer supports private GitHub repos - you don't need to register it to Packagist in order to work.
You should not keep your vendor directory in your version control. This is how it is done in Symfony Standard Edition and you should follow this. Running composer install command should be a part of your deployment process
Including vendor packages in your codebase is not recommended, so if you need to maintain the same version of the packages you use on your local machine, the best way is to keep composer.lock in the VCS and running only composer install on other environments.
Additionally, if you want the prod deployment to be instant, without depending on the composer process, you could run composer install on the dev server, and once it's validated you can make your prod deployment script copy the vendor folder from the dev env.
I'm new to Composer (getcomposer.org) and wasn't sure how it works if I install a package locally using Composer and then push my codebase to my production server using Git. Do I have to run Composer again on the production server?
cheers,
J
When you setup your project, you add your dependencies into your composer.json file in your local project directory.
Once you have done this, you will need to run composer update. You can also run composer install, however, without a composer.lock file, composer install actually runs composer update.
Composer update goes out and resolves all the dependencies of all the libraries you are using, downloads them to the /vendor directory, creates an autoloader script and generates the composer.lock file.
For your project what you want to do is version your composer.json AND your composer.lock file.
On your production server, you will always run composer install, which insures that the libraries on your production server are the exact same ones you utilized in your development process.
composer install is also a lot faster as it does not have to do all the dependency management work, and can almost always just pull a specific commit#. It doesn't have to look at version strings. Thus is is usually very fast, once a server has already gone through it once.
In development the only time you should run composer update, is when you introduce a new library OR you have an issue where an underlying library has been changed and you know that you need to have composer go out and re-calculate the dependencies. composer update always recalculates and downloads the latest revisions of any library available even if the version level did not change. This means that there is a potential for something to have become broken, necessitating the potential for as full a set of regression tests as you might have available. In short, something having nothing to do with what you're actually changing could have broken, so you only want to introduce the potential for change when you are forced to.
Of course, if you did introduce a new library, you have no choice but to run composer update.
Once you run composer update, your composer.lock file will be updated (as expected) and the production server will pick this up when you run composer install on it.
As others stated, put the vendors in your gitignore. The point is that these are external libraries that you depend on, but that do not belong in your project, and should not be versioned. In the old days some people utilized git submodules, and it's a big PITA you really want to avoid, not to mention that submodules don't address dependencies of the libraries you included.
It depends how are you working. If you, like getcomposer.org says, are ignoring the "vendor" folder then you need to run it again. If you are versioning the "vendor" folder then you don't need to run it again.
Have in mind that composer will get in charge of managing your dependencies versions, so there is no need to put your dependencies files under versioning. If you put these files under git you will only make your repository bigger.
Read https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies.
For clarification when you ignore the "vendor" folder Git don't track the files under the folder so if you clone the repo it will be like composer never was executed