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).
Related
In a life cycle of a php project we have
install: composer install
publish: composer push
But, what would be the command to build a php project with composer?
what would be the command to build a php project with composer?
Simply speaking, you build the PHP project. Composer is a utility you can use to manage a PHP projects dependencies. Additionally you can also use it to define your PHP project.
How you build the PHP project is entirely up to you. This is normally dependent of what kind of PHP project that is and how you organize it.
To give an example: Lets consider your PHP project just is the project directory with the composer.json at its root with all the other sub-directories and files.
Composer operates within that directory. So when you want to create a build artifact of that project you do the following:
composer install --no-dev - Prepare the vendor folder with the production dependencies and the autoloader.
composer archive - Create the build artifact.
As you will do this quite often and over and over again you could add a Composer Script named build or similar to put things together:
{
"scripts": {
"build": [
"#composer --no-plugins --no-interaction install --no-scripts --no-dev",
"#composer --no-plugins --no-interaction archive"
]
},
"scripts-descriptions": {
"build": "Build project artifact."
}
}
You can then run:
$ composer build
...
Composer will then output the file-name. By default it should be a .tar file (tarfile, tarball), you can inspect it on the commandline with the tar utility (here gnutar):
$ tar -tvf "$(composer show -sN | sed 's|/|-|')"*.tar | less
And that would be the example. Whatever composer push is, I don't know. It is likely that you have it somewhere in your Composer configuration. So I can't comment on it.
To extend a bit on the given example: I manage most (if not even all) of my PHP projects with Composer. However this is not the full truth. I actually version control them with Git. Looking from a birds perspective, the Git utility is way more leading than the Composer utility. That is for example, that I want to be able to build a specific git revision.
Now Composer is not that bad with Git. It recognizes if the project exists and in case of the composer archive example, it even puts the git revision hash into the file name of the build artifact.
However Composer operates in-tree. That is the place where the development happens as well, so this can easily clash (you don't want the build to remove the development dependencies while you're running tests as well - or afterwards). And even Composer recognizes that the project is managed by Git, it is otherwise a bit dumb as Composer is merely concerned about the dependencies and knows very little about the project itself - it can't just guess how you manage the overall project.
So what then commonly happens is that you still use Composer during the build but you have a dedicated build process and runner that knows the ins and outs of the project and its build.
$ make
is such a runner. Works with a Makefile in the project, e.g.
$ make deploy
knows when it needs to build again. And speaking of PHP projects: It certainly can just rsync to remotes and run smoke-tests to mark the deployment as green (use old, dumb tech and keep it simple).
I've just come across the https://github.com/FriendsOfPHP/security-advisories tool which looks a great way to automatically scan for the vulnerabilities that are in that community-contributed database.
It scans a composer.lock file for packages with vulnerabilities. However, it's made me realise that my understanding of Composer is not what it should be!
I have a project that has a composer.json file that requires a single demo/package. That demo package also has requirements, like demo/dep.
The result of running composer install --no-dev is that I have a composer.lock file which includes:
demo/package version 1.0
demo/dep version 1.2
All good so far, and running symfony security:check /path/to/my/project/composer.lock gives me a green light, no vulnerabilities.
However on close inspection of the files now in my vendor dir, I can see there's a vendor/demo/package/composer.lock file, which contains references to demo/dep at version 1.1 - which has a security vulnerability against it.
As I understand, I have the safer 1.2 version installed - so says my project's composer.lock file, but why is a composer.lock file included with the vendor's package?
Does that mean that the dodgy code is installed somewhere, too? Or can I just simply ignore the composer.lock files if there's a composer.lock file in a dir above it or such? composer show does not list the versions in the nested lock file. Or maybe I should ignore composer.lock files if there's no sibling ./vendor/ dir?
Why not simply inspect your folders to find a vulnerable version? If there was any, you should find a vendor folder within that package, that's where that package could have installed stuff from it's own composer.lock
Usually, only the composer.json of a package is evaluated to install dependencies. If there is a lock file within one package's folder, you should ask the maintainer of that package why this is the case, but for installing dependencies on your system, this does not matter.
Side note: writing "usually" refers to the standard model of installations. I've seen some crude stuff where Composer plugins put other rules in place, but this cannot be said for your project without knowing more about the structure.
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.
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.