Using composer in a php project for beginners

I won’t write how to use composer, but I want to share my practice. I hope my advice will be useful to someone.

Use fewer packages, the fewer the better.
If you can do without the package, do so. Better to have your own service or component. No, this is not reinventing the wheel. Firstly, learn to write your own components, and secondly, it’s more reliable. It only makes sense to reclaim a package if you are in very aggressive development or it will save you a few weeks. 95% of all public projects are garbage, and 80% will no longer be supported in the next 5 years.

Some dependencies create such cohesion in the code that getting rid of them becomes a huge problem (note: validation, forms, API components, ORM).

We simply copy small packages into the code.
Sooner or later, if the project lives long enough, we are faced with an unpleasant situation – that the package has become abandoned, i.e. lost its contributor and is no longer updated, and has become incompatible with new versions of php. The obvious “smart” solution is to fork it and maintain the version yourself. In fact, you just need to do ctrl+c ctrl+v, forgetting forever about the need to update it.

When and how to update
When you update one individual package, you risk that a new bug will break part of your system. Therefore, you only need to update the package if you have a compelling reason.

An example of a compelling reason to upgrade a package:

1. the emergence of a new feature that you need

2. closing the vulnerability

3. performance boost

4. update as dependencies, for example when updating php version

At these moments you will be glad if you have tests

Updating symfony, laravel and php
In general the rule is that php is being updated after the second patch of the minor version, so as not to catch a severe php runtime bug in the project (8.0.2, 8.1.2 ….)
Symfony offers LTS (long term support) versions, you need to focus on them; as soon as such a version is released, you should add the task to the backlog.
There should be no sudden package updates. Either we work with technical debt and do an upgrade, or we update the package as part of the task in which it is required.
Laravel updated once a year, optimally updated once a year, it's usually worth it. And/or if you really need some new feature. The accumulation of backlog entails problems in the future.

Don't forget to read the patch notes, maybe you can improve your project with new features.

Sequence when updating php:
First, we update the php version, then we update new versions of the main components (laravel, symfony), then the rest. Inevitably we encounter conflicts, all the abandoned repositories and packages with slow version updates will come out.
The -W option allows you to update packages along with dependencies. If the update in pieces does not work, we begin to assemble the project in composer again. We write out all the used packages and reclaim them one by one.
You can reclaim several packages at once, separated by a space.

Strategy for working with composer.lock

1. composer.lock should be in the repository. This ensures predictability of the environment. The best practice is to ensure that the server and local environments (and all other environments in which the program runs) are identical.

2. How to merge composer.lock in case of conflict? – when merging, we generate .lock again, you can also simply update the hash “composer update –lock”