5 ms·

After using Composer for some years I think these tips are good to think about: * Use full version numbers for your dependencies. * Include the vendor fold

by pasta 8y ago

After using Composer for some years I think these tips are good to think about: * Use full version numbers for your dependencies. * Include the vendor folder in your VCS. The last one I had to think about a lot but it's a real pain to get an old project working again when dependencies are no longer available. Unfortunately this happens a lot.

stunt 8y ago
You always choose a reliable dependency not something random. I never had similar experience or saw a project doing that. You should only version composer.lock and composer.json files. Ignore vendor directory and leave that job to your build step in CI/CD...
- viraptor 8y ago
  Things disappear, or get deleted, or old versions get replaced for various reasons. There's no "reliable dependency". Even if you think something's reliable, sone deeper dependency may disappear. See npm and left-pad for example. Committing vendor directory may or may not be a good idea. But having your own copy of all dependencies (current and past) is necessary.
  - marenkay 8y ago
    > But having your own copy of all dependencies (current and past) is necessary. Definitely! Git mirrors are cheap, and there are various solutions for composer proxies out there. If you consider CI/CD you will want freedom from external calls anyway.
- mnemnc 8y ago
  That's why we have our own composer repository powered by satis. When set up correctly, it can be used as a "proxy" for packagist, ensuring you always have an installable version of your dependencies, even if they are not available via packagist anymore.
  - dotancohen 8y ago
    Most insightful comment on this thread. I'm looking into satis now, thank you! https://github.com/composer/satis https://github.com/composer/satis
marenkay 8y ago
Major and minor versions usually are sufficient, as you can lock to a specific version anyway. You should never VCS the vendor directory. If you are concerned about disappearing 3rd party dependencies, you should: - have a local cache - keep e.g. git mirrors for 3rd party dependencies - invest a bit more time in selecting dependencies with higher quality. I've seen repos with vendors checked in. A few years, hundreds of thousands of commits, and even a git status takes 30 seconds to run. Just saying, there is a more sensible approach that beats storing vendors in the project :-)
- pjmlp 8y ago
  While sensible advice, usually only the VCS approach works across many organizations, which don't provide the resources to do it in any other more reasonable way.
- deleted 8y ago
  [deleted]
- gkya 8y ago
  Checking your dependencies in is a good idea. When you check out a version from some time ago, you won't have to worry if those versions are still available in your cache or on remotes. Especially if the package manager is not very dependable. Furthermore, if you patch or edit your dependencies, that information is permanently recorded too.
  - sopooneo 8y ago
    At my job we almost never version control our vendor directory, but you have a very strong point, and I am not strongly in our camp. One pain point in particular, is that if you are using Git Bisect to find out where a bug appeared, and you don't have your dependencies version controlled, you either have to run "composer install" at each bisect step, or set up an equivalent checkout hook. And while I guess the checkout hook could work, it is going to make a lot of other work a lot slower.
- roel_v 8y ago
  "and even a git status takes 30 seconds to run" That's a problem with your vcs, not with the (defensive) practice of tracking external dependencies.
fredsted 8y ago
Your build system should take care of this for you. For example, build a docker image or store an artifact (e.g. zip file) of the full build including dependencies. Then put it on your own docker registry or the artifact on S3, for example.
waibelp 8y ago
Instead of including the vendor folder into projects you may use satis [0] to "mirror" all of your dependencies. That means you will not have any broken stuff if packagist is down or any of your dependencies are missing. [0]: https://github.com/composer/satis https://github.com/composer/satis
Seldaek 8y ago
IMO for the first point you should rather use ^x.y with the minimum version you require and then accept new releases as they come. If you do regular updates you should notice quickly when something break and be able to revert that update easily. If you update 20 packages at once it becomes harder to pinpoint where a regression occurred. As for including the vendor dir in your VCS repo, this comes with quite a few drawbacks. That's one of the things Private Packagist (https://packagist.com https://packagist.com) aims to fix though, as it keeps mirrored copies of your dependencies' zip archives so you get more reliable installs.
- Double_a_92 8y ago
  What guarantees you that packagist will be around in e.g. 15 years when you would like to start some old project?
  - Seldaek 8y ago
    If you are talking about such long time frames, then indeed archiving a project with its vendor directory might be a good idea once you decide to relegate it to the freezer.
    - Piskvorrr 8y ago
      How about "vendor decided to migrate off Github last week, and managed to break all their tags in the process"? (Not that this would have actually happened to me this Monday, noooo ;)) Long timeframes are not the only issue with external dependencies...
  - krapp 8y ago
    You don't need (and shouldn't depend on) packagist when using Composer. You can import packages directly from Github, Bitbucket, etc., or even locally, you just have to write a bit more JSON.
    - mrrsm 8y ago
      What do you suggest when the package you are using is pulling in other packages from packagist?
hrktb 8y ago
> * Use full version numbers for your dependencies. The tradeoff for this approach is to have to resolve version conflicts manually anytime there is more than minor dependency changes. In particular, adding a package that is newer than most of your dependencies can be a nightmare when you locked down all the working revisions of your libraries. On one hand there is less drama about packages changing under one's feet, on the other hand part of composer's job is shifted back to the dev who does the package updates. Personally I would advise a more balanced approach of allowing minor version changes and only block major ones.

by pasta 8y ago

stunt 8y ago

You always choose a reliable dependency not something random. I never had similar experience or saw a project doing that. You should only version composer.lock and composer.json files. Ignore vendor directory and leave that job to your build step in CI/CD...

viraptor 8y ago
Things disappear, or get deleted, or old versions get replaced for various reasons. There's no "reliable dependency". Even if you think something's reliable, sone deeper dependency may disappear. See npm and left-pad for example. Committing vendor directory may or may not be a good idea. But having your own copy of all dependencies (current and past) is necessary.
- marenkay 8y ago
  > But having your own copy of all dependencies (current and past) is necessary. Definitely! Git mirrors are cheap, and there are various solutions for composer proxies out there. If you consider CI/CD you will want freedom from external calls anyway.
mnemnc 8y ago
That's why we have our own composer repository powered by satis. When set up correctly, it can be used as a "proxy" for packagist, ensuring you always have an installable version of your dependencies, even if they are not available via packagist anymore.
- dotancohen 8y ago
  Most insightful comment on this thread. I'm looking into satis now, thank you! https://github.com/composer/satis https://github.com/composer/satis

marenkay 8y ago

Major and minor versions usually are sufficient, as you can lock to a specific version anyway. You should never VCS the vendor directory. If you are concerned about disappearing 3rd party dependencies, you should: - have a local cache - keep e.g. git mirrors for 3rd party dependencies - invest a bit more time in selecting dependencies with higher quality. I've seen repos with vendors checked in. A few years, hundreds of thousands of commits, and even a git status takes 30 seconds to run. Just saying, there is a more sensible approach that beats storing vendors in the project :-)

pjmlp 8y ago
While sensible advice, usually only the VCS approach works across many organizations, which don't provide the resources to do it in any other more reasonable way.
deleted 8y ago
[deleted]
gkya 8y ago
Checking your dependencies in is a good idea. When you check out a version from some time ago, you won't have to worry if those versions are still available in your cache or on remotes. Especially if the package manager is not very dependable. Furthermore, if you patch or edit your dependencies, that information is permanently recorded too.
- sopooneo 8y ago
  At my job we almost never version control our vendor directory, but you have a very strong point, and I am not strongly in our camp. One pain point in particular, is that if you are using Git Bisect to find out where a bug appeared, and you don't have your dependencies version controlled, you either have to run "composer install" at each bisect step, or set up an equivalent checkout hook. And while I guess the checkout hook could work, it is going to make a lot of other work a lot slower.
roel_v 8y ago
"and even a git status takes 30 seconds to run" That's a problem with your vcs, not with the (defensive) practice of tracking external dependencies.

fredsted 8y ago

Your build system should take care of this for you. For example, build a docker image or store an artifact (e.g. zip file) of the full build including dependencies. Then put it on your own docker registry or the artifact on S3, for example.

waibelp 8y ago

Instead of including the vendor folder into projects you may use satis [0] to "mirror" all of your dependencies. That means you will not have any broken stuff if packagist is down or any of your dependencies are missing. [0]: https://github.com/composer/satis https://github.com/composer/satis

Seldaek 8y ago

IMO for the first point you should rather use ^x.y with the minimum version you require and then accept new releases as they come. If you do regular updates you should notice quickly when something break and be able to revert that update easily. If you update 20 packages at once it becomes harder to pinpoint where a regression occurred. As for including the vendor dir in your VCS repo, this comes with quite a few drawbacks. That's one of the things Private Packagist (https://packagist.com https://packagist.com) aims to fix though, as it keeps mirrored copies of your dependencies' zip archives so you get more reliable installs.

Double_a_92 8y ago
What guarantees you that packagist will be around in e.g. 15 years when you would like to start some old project?
- Seldaek 8y ago
  If you are talking about such long time frames, then indeed archiving a project with its vendor directory might be a good idea once you decide to relegate it to the freezer.
  - Piskvorrr 8y ago
    How about "vendor decided to migrate off Github last week, and managed to break all their tags in the process"? (Not that this would have actually happened to me this Monday, noooo ;)) Long timeframes are not the only issue with external dependencies...
- krapp 8y ago
  You don't need (and shouldn't depend on) packagist when using Composer. You can import packages directly from Github, Bitbucket, etc., or even locally, you just have to write a bit more JSON.
  - mrrsm 8y ago
    What do you suggest when the package you are using is pulling in other packages from packagist?

hrktb 8y ago

> * Use full version numbers for your dependencies. The tradeoff for this approach is to have to resolve version conflicts manually anytime there is more than minor dependency changes. In particular, adding a package that is newer than most of your dependencies can be a nightmare when you locked down all the working revisions of your libraries. On one hand there is less drama about packages changing under one's feet, on the other hand part of composer's job is shifted back to the dev who does the package updates. Personally I would advise a more balanced approach of allowing minor version changes and only block major ones.