Why should always run ‘composer install’ in production?

In the fast-changing world of web development, where apps always change to fit new needs, controlling what your app relies on is super important to keep it stable and reliable. Composer is a popular tool for PHP developers to handle these dependencies well. But there’s one command, composer update that can cause issues if used in a live environment. This article looks into why it’s risky to run composer update in production and suggests safer ways to handle your app’s dependencies without risking its stability.

Understanding Composer: The PHP Dependency Manager

Before we dive into why you should use composer install in production, it’s essential to understand what Composer is and its role in PHP development. Composer is a dependency manager for PHP, offering a streamlined solution to handle libraries and packages within a project. It simplifies the process of managing external dependencies, allowing developers to define and install the libraries their project relies on.

Composer operates based on a composer.json file, where developers specify the required dependencies and their versions. The accompanying composer.lock file records the exact versions of these dependencies installed in the project. When composer install is executed, Composer reads these files and installs the specified versions, ensuring consistency across different environments.

The true power of Composer lies in its ability to resolve and manage dependencies recursively. It not only installs the direct dependencies but also handles the dependencies of those dependencies. This recursive approach ensures that the entire project ecosystem is in sync, with compatible versions of libraries working harmoniously.

While Composer is an invaluable tool for managing dependencies during development, caution arises when considering its usage in production. The delicate balance between keeping dependencies up-to-date and maintaining the stability of a live application is a crucial aspect of effective software development and deployment.

Understanding composer install vs. composer update

To comprehend the apprehension around composer update, it’s crucial to distinguish between composer install and composer update. While composer install installs dependencies based on the exact versions specified in the composer.lock file, composer update goes a step further by updating all dependencies and generating a new composer.lock file. This key distinction sets the stage for potential issues when updating dependencies in a live production environment.

The Locking Mechanism

The composer.lock file serves as a snapshot of the exact versions of dependencies that your application is using. When you run composer install, it installs the versions specified in this lock file, ensuring consistency across different environments. On the other hand, composer update discards the existing lock file, potentially introducing newer versions of dependencies, which might lead to compatibility issues.

Versioning Strategies and Dependency Constraints

When you manage dependencies with Composer, you must use the version constraints skillfully. Most importantly, you need to ensure that the constraints afford you instability and compatibility across your project. It will allow you to specify the version constraints in your composer.json file. This is a flexible way to manage updates. For instance, if I were to say ^1.2, I would ensure that any new versions of a package that are backward compatible with the old versions are indeed counted as compatible by Composer. That would mean – if we’re talking about specific numbers – that 1.2.x, 1.3.x, and such up to 2.0 would be okay for the composer to count as compatible.

To exert more control, you can set dependencies to a precise version, such as 1.2.3. This guarantees that just this version gets installed, which aids in making sure that critical dependencies – and the parts of my application that really need to be stable – are as stable as possible. When you install from a more controlled environment, you really don’t want the installation to be pulling in unstable versions of the dependencies, especially transitive dependencies. But in setting these fixed versions, you lose the freedom to pull in new minor or patch versions of the dependencies you see listed in the table above. When you see those new versions, they’re typically fresh with important bug fixes, security patches, or new features. As a general rule, always set sensible version constraints and avoid using wildcards (e.g., *), as they can lead to unexpected breaking changes.

Examples:

• "symfony/symfony": "^5.3" (Allows updates to any 5.x version)
• "guzzlehttp/guzzle": "~7.2" (Allows updates to any 7.x version but not 8.x)
• "monolog/monolog": "2.3.1" (Locks to version 2.3.1, no updates allowed)

Handling Security Updates

Ensuring your application’s dependencies are secure is vital. Several methods exist for effectively managing the security updates of Composer dependencies. The most effective way is also the simplest: regularly check dependencies for vulnerabilities, and update any that do have them. The security checker built into Composer itself can carry out this simple task. When you run composer audit the plugin checks your lock file against a public database of known issues; if a vulnerability is found, it tells you which package is affected and what the nature of the problem is.

Moreover, to guarantee the application of security patches without compromising stability, employ conservative version constraints like ^ or ~. These constraints let through just minor updates and patches, but not major updates that could break your app.

For instance, if you use ^1.2 for a library, you get all the updates in the 1.x series without being bumped up to 2.0, which might not be backward-compatible with 1.x. Running composer outdated --direct every now and then helps you keep tabs on the direct dependencies that need updates.

Examples:

• Run composer audit to check for known vulnerabilities.
• "symfony/symfony": "^5.3" (Allows updating to the latest security patches in 5.x without jumping to 6.x).
• Using "roave/security-advisories": "dev-latest" ensures insecure versions of dependencies are blocked from being installed.

Composer Scripts

You can use the composer scripts to execute certain tasks before or after specific composer commands, allowing you to automate your development and deployment workflows. You define custom composer scripts in the “scripts” section of your “composer.json” file. When you run “composer install,” “composer update,” or other composer commands, they don’t usually execute (unless you’ve asked for them to execute specifically). Of course, with PHP, you can do anything you need to do, and many people use just plain PHP for this. But if you’re doing something that’s relatively trivial, like automating a few doc generation commands, or if you’re doing something that’s relatively shell-like in nature, Composer provides a mechanism for you to invoke an “external command” from your script. When you run the external command, you’re telling Composer to execute a command in the environment where it’s working. For instance, a common use case is running composer dump-autoload -o after installing or updating dependencies to optimize the autoloader for production environments.

Examples:

"scripts": {
  "post-install-cmd": [
    "php artisan clear:cache",
    "composer dump-autoload -o"
  ],
  "post-update-cmd": [
    "vendor/bin/phpunit"
  ]
}

• Automatically clear cache and optimize autoloading after composer install.
• Run phpunit tests after an update to ensure everything works as expected.

The Fear of Breakage

The fear associated with running composer update in production stems from the unpredictability introduced by updating dependencies. Even with tight version constraints your composer.json, the recursive nature of Composer may lead to updates in your dependencies’ dependencies. While most updates won’t cause problems, there’s a risk that a behavior change introduced several layers down the dependency chain, could impact your code in unanticipated ways.

Real-World Scenarios

Consider a situation where a critical extension, such as the pcntl module, requires an update. The temptation to run composer update to address this issue might arise. However, doing so in a production environment could lead to unforeseen conflicts and breakages, especially if the update introduces changes that haven’t been thoroughly tested against your application.

Best Practices: Always Run Install in Production

Given the potential risks, experienced developers often advise against running composer update directly in a production environment. Instead, a more structured approach is recommended:

1. Perform Updates Elsewhere: Execute composer update in a development environment or a dedicated staging server. This allows you to assess the impact of updates without risking the stability of your live application.
2. Separate Environments: Create a separate copy of your application, ensuring that the updating process does not interfere with the live application being served to users.
3. Deploy a Fresh Installation: If updates are necessary, opt for composer install to create a fresh installation based on the existing composer.lock file. This approach provides more predictability and reliability compared to the potentially unpredictable nature of composer update.
4. Optimize and Test: Before deploying to production, optimize your autoloader, run after-install scripts, and thoroughly test the new version in a staging environment. This step ensures that any potential issues are identified and addressed before reaching the live environment.
5. Use Deployment Tools: Composer is primarily a dependency management tool, not a deployment tool. Consider utilizing dedicated deployment tools to push your code to production. This could involve code deployment tools or even simple scripts for tasks like FTP uploads.
6. Symlink for Swift Updates: To minimize downtime and avoid impacting a running application, consider using a symlink as the “production” root. This allows for quick updates by replacing the symlink with the new release once the deployment is ready.

Conclusion

In conclusion, the caution surrounding composer update in production is rooted in the potential risks associated with dependency changes. By adhering to best practices, such as updating dependencies in a controlled environment, thoroughly testing updates, and deploying with precision, developers can strike a balance between keeping their applications up-to-date and ensuring the stability of live production systems. Remember, the key is to approach dependency management with care and strategic planning to mitigate the risks inherent in dynamic software ecosystems.