4 ms·

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

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?
    - krapp 8y ago
      Rewrite your composer.json to include them directly?. The lock file probably contains the actual repository URLS so once you have a dependency tree resolved you can rewrite it based on that. But it is possible to avoid packagist. Ugly and painful maybe but possible, and YMMV regarding the effort being worth the reward. Dependency management in PHP isn't (or shouldn't be) like it is with JS/Node where there is one authoritative registry that everyone has to depend on and that can assert direct influence over the community as a result. Packagist shouldn't be the PHP package registry, but a registry.
- Aeolun 8y ago
  The fact that I need packagist, and the basic structure is really easy to copy? If not packagist, then someone will have set up a package repository with a different name.

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?
  - krapp 8y ago
    Rewrite your composer.json to include them directly?. The lock file probably contains the actual repository URLS so once you have a dependency tree resolved you can rewrite it based on that. But it is possible to avoid packagist. Ugly and painful maybe but possible, and YMMV regarding the effort being worth the reward. Dependency management in PHP isn't (or shouldn't be) like it is with JS/Node where there is one authoritative registry that everyone has to depend on and that can assert direct influence over the community as a result. Packagist shouldn't be the PHP package registry, but a registry.
Aeolun 8y ago
The fact that I need packagist, and the basic structure is really easy to copy? If not packagist, then someone will have set up a package repository with a different name.