Home • Explore • Blog • Models • CI
☰



nixpkgs
3rd chunk of `doc/languages-frameworks/php.section.md`
1113d925fcdb11936877c17d3cf0467c867b0837cc1a610b00000001000009aa
development process.

Composer is not a package manager in the same sense as `Yum` or `Apt` are. Yes,
it deals with "packages" or libraries, but it manages them on a per-project
basis, installing them in a directory (e.g. `vendor`) inside your project. By
default, it does not install anything globally. This idea is not new and
Composer is strongly inspired by Node's `npm` and Ruby's `bundler`.

Currently, there is no other PHP tool that offers the same functionality as
Composer. Consequently, incorporating a helper in Nix to facilitate building
such applications is a logical choice.

In a Composer project, dependencies are defined in a `composer.json` file,
while their specific versions are locked in a `composer.lock` file. Some
Composer-based projects opt to include this `composer.lock` file in their source
code, while others choose not to.

In Nix, there are multiple approaches to building a Composer-based project.

One such method is the `php.buildComposerProject2` helper function, which serves
as a wrapper around `mkDerivation`.

Using this function, you can build a PHP project that includes both a
`composer.json` and `composer.lock` file. If the project specifies binaries
using the `bin` attribute in `composer.json`, these binaries will be
automatically linked and made accessible in the derivation. In this context,
"binaries" refer to PHP scripts that are intended to be executable.

To use the helper effectively, add the `vendorHash` attribute, which
enables the wrapper to handle the heavy lifting.

Internally, the helper operates in three stages:

1. It constructs a `composerRepository` attribute derivation by creating a
   composer repository on the filesystem containing dependencies specified in
   `composer.json`. This process uses the function
   `php.mkComposerRepository` which in turn uses the
   `php.composerHooks.composerRepositoryHook` hook. Internally this function uses
   a custom
   [Composer plugin](https://github.com/nix-community/composer-local-repo-plugin) to
   generate the repository.
2. The resulting `composerRepository` derivation is then used by the
   `php.composerHooks.composerInstallHook` hook, which is responsible for
   creating the final `vendor` directory.
3. Any "binary" specified in the `composer.json` are linked and made accessible
   in the derivation.

As the autoloader optimization can be activated directly within the
`composer.json` file, we do not enable any autoloader optimization flags.
Title: Building PHP Composer Projects with Nix: `php.buildComposerProject2`
Summary
This section details how Composer functions as a per-project dependency manager for PHP, distinct from global package managers like Yum or Apt, and how its dependencies are defined in `composer.json` and `composer.lock` files. It introduces Nix's `php.buildComposerProject2` helper function, a wrapper around `mkDerivation`, designed to streamline the building of Composer-based projects. This helper automatically links binaries specified in `composer.json` and requires a `vendorHash` attribute. The internal process of `php.buildComposerProject2` involves three stages: constructing a `composerRepository` derivation (using `php.mkComposerRepository` and a custom Composer plugin), creating the final `vendor` directory from this repository via `php.composerHooks.composerInstallHook`, and linking any binaries. Autoloader optimization is not enabled by default, as it can be configured directly within `composer.json`.