Me and my team are working on a project that uses Composer for dependency management. There seems to be a difference in how a composer update is handled on several machines (running the same latest build version of Composer), but we can't figure out why.
When my teammate runs a composer update on a dependency it tries to remove a lot of data/nodes from the composer.lock file (like the entire dist and support nodes):
When I run the same update, it tries to re-add all those keys again:
We can't figure out why this is happening. Is this a certain setting?
Update: On further inspection, it appears that the "(dis)appearing" nodes all contain https links, could it have something to do with a (missing) SSL library or something?
It seems that one Composer prefers dist and one prefers source.
Look into ~/.composer/config.json if you defined a preferred install in any of your two composers. Or if you defined different preferred installs in the composer.json.
"config": {
"preferred-install": "dist"
}
You can force composer to use either dist or source with
composer update --prefer-dist
or
composer update --prefer-source
--prefer-source: There are two ways of downloading a package: source and dist. For stable versions composer will use the dist by default. The source is a version control repository. If --prefer-source is enabled, composer will install from source if there is one. This is useful if you want to make a bugfix to a project and get a local git clone of the dependency directly.
--prefer-dist: Reverse of --prefer-source, composer will install from dist if possible. This can speed up installs substantially on build servers and other use cases where you typically do not run updates of the vendors. It is also a way to circumvent problems with git if you do not have a proper setup.
Related
Since composer was created, it made our life a lot easier. However, running composer install often ends up with so many files that can be useful for development, but just bloat the production server. Shared hosting often has limited inodes, or you must upload the "vendor" folder yourself since composer isn't on the server.
When the vendor folder has 6,000 files+ this is an issue, especially if you have multiple projects with 6,000 files each. And so many of these files are "README.MD" or "TODO". Production servers don't need the dev's "TODO" file.
I tried searching on Google but I can't find any clues, so anyone knows if there is a composer command that will install a production version?
There was a feature request for that, but it was rejected (several times). Right now the best what you can get from Composer is:
composer install --no-dev --prefer-dist
It will skip installation dev packages and prefer dist archives, which usually does not contain tests and other files not necessary to run package on production.
If this is still not enough, you may try to use octolab/cleaner plugin.
composer install --no-dev
The official link:
https://getcomposer.org/doc/03-cli.md#install
If you want to exclude something very specific, you want archive.
https://getcomposer.org/doc/04-schema.md#archive
"archive": {
"exclude": ["*.md", "vendor/**/tests", "/*.test"]
}
I know that we can always install a package via command:
composer require packageA
But I don't know if you guys ever have a situation like this:
You want to install a big size package "packageB" that your teammate added to composer.json and your wifi is slow so composer would take very very long to get the packageB. Then you have an idea:
"Maybe I try get the packageB zip from my teammate via flash drive and paste
it into my project."
And you did that, the package works as expected. Wonderful!
But then, you think again:
What if now I want to do the composer update other packages in my
project?
You try:
composer update
and then, what happen is composer will get the package again because you didn't use "composer install" or "composer update" to install packageB so composer doesn't know you have it.
(Sorry for the long explanation).
So my question is:
How do we let composer know that we have the package already so composer don't re-download the package again? Or this is the behavior of composer and I must always use "composer install/update", there is no other way?
And sorry, change to another wifi or find a faster internet connection is really not what I'm looking for. And I also know that we can install the package locally (see here: How to update a single composer package?).
Thanks in advance!
If we don't want to use repositories.
In my knowledge, the only option is to update you composer.json and composer.lock. Friend give you version 1.2 to vendor? Write in exactly version in composer.json and for composer.lock, you will need data from your friend too.
Run install then.
Should check, but not download any file. Still, problem is that all required libraries by this library, could be updated - you can only write down exactly version of them in file.
As default, I think, the didn't predict scenarios for that way.
This is the only solution for you, i know should work.
Composer does use caching heavily to reduce the amount of data to download. However this does not remove the need to download the package at least once.
Basically Composer has two modes to download: --prefer-dist will try to obtain a download URL for an archive file, and --prefer-source will try to obtain a copy of the version control system being used.
Both variants put the result into Composer's cache directory.
Over time you'll collect a couple of archive files locally, which allow for quick switches back and forth between existing version downloads, and newer versions will have to be downloaded once.
Also you can clone a git repository once, and Composer will try to reuse it when updating, by simply fetching new commits and checking out the appropriate tags. This still requires to clone the repository once.
You can work around cloning the repository by manually placing it at the correct spot, either by physically putting it there, or by symlinking the correct vendor directory. You can also make Composer aware of an official copy by adding the local copy as an entry to repositories. This will add this source to the existing collection of packages available from Packagist.
When I do composer install on the production system, should I use the flag --prefer-dist?
--no-dev is recommended, since it prevents the installation of packages that are only needed during development. But what is with --prefer-dist? This flag makes that the installed packages are without VCS stuff, as I read in this answer. I assume that I don't need this on a production machine. Am I right?
The dist file (e.g. tar archive) is usually quicker to download than cloning the repository (which is the case when using --prefer-source).
The main difference is that cloning the repository will give you everything, while a lib maintainer can create the dist itself. This means that they might not include the tests in the dist file for instance. That's why people suggest using --prefer-dist, as it might end up downloading less files.
Anyway, --prefer-dist isn't really needed as Composer always defaults to the dist file when downloading a stable dependency. As it's really a bad practice to have unstable dependencies running in production, you probably end up downloading the dist for all packages anyway (unless you use --prefer-source of course).
My workflow for developing Symfony bundles is the following:
install Symfony
create a git repo for the new bundle, put a composer.json file in there
require the new package in the top-level composer.json, using #dev version
composer update newpackage => the package is downloaded, using git clone
work on the git clone inside vendors, committing and pushing from it
This is all fine and dandy, but seems to break in one specific case:
if I alter the 'autoload' tag of the already-installed package, it seems that Composer has a hard time taking it into account:
I tried 'composer dumpautoload', and it does nothing
I do not want to remove the composer.lock file, as I do not want other packages to be updated to a newer version, I only want to alter the autoload config of that one package
I tried removing by hand vendor/composer/installed.json, and what happened is that Composer re-downloaded all the vendors and wiped any data which happened to be in there at that moment
The same problem manifested itself when I did alter the autoload section of the package on a separate clone, pushed the changes to git and ran 'composer update mypackage' - although that might have been related to packagist not having received the ping from github.
I can of course alter by hand the composer.lock and vendor/composer/installed.json files, but that seems too hackish. It also does not gives the guarantee that user downloading the package the 1st time will see it working.
Try:
./composer.phar dumpautoload -o
It reads the composer.json files and rewrites all the autoload files which pick up the new paths.
dumpautoload uses the package information from vendor/composer/installed.json and not the individual composer.json files. You need to change the autoload info there, too.
The file installed.json is only being update when you run a
composer update
I'm trying to make composer update only newly added packages to composer.json i.e when I manually add a package dependency to the composer.json file, it should update the composer.lock file only for the new package; the rest of the packages should be at the same version as before. I tried running composer update --lock but I don't think it does what I'm trying to achieve and it took a lot of time to finish. I checked the commands on composer's documentation but can't find one to achieve my wish. Any advice or workaround will be appreciated.
Note: I'm using Laravel Forge, so there is a 2 minutes deployment limit.
In order to install only new packages with composer you should run
composer install
Because composer update will install your new packages but will update and all the other already installed packages.
You can specify the name of the package as an argument to the update command. This will perform a partial update: composer update the-package/you-want-to-update
I think your question is related to your (guessed) current workflow: To add a new package you edit the composer.json file and then run composer update - wishing to only add/update that new file.
If that is true, here is the solution:
composer require new/package will add the newest possible version (taking into account the currently installed packages) of the new package. Benefits: Only one command line, and no fiddling with JSON content.
If you already know which version you want, you could also run composer require new/package:^2.1.25#beta (or whatever version and stability level you want - this example is exaggerating a bit). If this version is incompatible with existing packages, nothing will get installed, everything will get rolled back, and you get an error message.