- How do I install bruli/php-git-hooks in a Laravel project?
- Install it as a Composer dev dependency in the Laravel repository, then verify that the expected hook files appear under .git/hooks after installation. Because it is a Composer plugin, Composer 2 may prompt you to allow the plugin, so add the package to your allow-plugins configuration if your team uses that policy. Pin the version and test the install in a disposable clone first, since the last release was in 2018 and modern PHP and Composer compatibility must be validated.
- What can I run in a pre-commit hook with this package?
- You can configure hooks to call arbitrary commands or Composer scripts, such as Laravel Pint, PHPStan or Larastan, PHPUnit or Pest, and frontend lint checks. Keep the pre-commit hook narrow and fast, then move slower checks to pre-push or continuous integration. The package is a thin hook orchestrator, so it wraps your existing project commands rather than replacing your quality tooling.
- Is bruli/php-git-hooks Laravel-specific or does it work with any PHP project?
- It is a Composer plugin for managing Git hooks in PHP projects, not a Laravel-only package. It fits Laravel teams well when the hooks call existing Composer scripts and Laravel conventions such as Pint, Larastan, and Pest. Your Laravel version is not directly constrained by the package, but PHP and Composer compatibility still needs testing.
- Does it support Laravel 10, 11, or 12?
- The package does not appear to declare Laravel-specific version support because it operates at the Git hook and Composer level. In practice, compatibility depends on your PHP version, Composer 2 plugin permissions, and whether the package installs cleanly in your environment. Treat Laravel 10, 11, and 12 support as something to prove in a pilot repository rather than assume, given the package is unmaintained.
- Will it install on PHP 8.2 or 8.3 with Composer 2?
- That must be tested directly, because the package has not had a release since 2018 and may lack modern PHP version constraints or Composer plugin metadata. Composer 2 may require an explicit allow-plugins entry before the plugin can run. If installation fails or behaves inconsistently, plan to fork the package or replace it with an actively maintained hook manager.
- Does it work in CI, Docker, or non-interactive Composer installs?
- Git hooks are primarily local developer tooling, and CI environments often do not have a writable .git directory or an interactive Composer run. Use flags such as no-dev or no-scripts where appropriate, and keep CI as the authoritative quality gate. Do not rely on this package to enforce checks in containers or continuous integration.
- Can developers bypass hooks, and how should we handle that?
- Yes, developers can bypass local Git hooks with git commit --no-verify, and some environments may skip hook installation entirely. Treat hooks as fast feedback rather than enforcement, and keep CI checks mandatory. Document the emergency bypass procedure, monitor bypass frequency, and provide a clear recovery path when hooks are missing after a fresh clone.
- What are good alternatives if bruli/php-git-hooks is unmaintained?
- Consider actively maintained options such as CaptainHook, Lefthook, Husky for JavaScript-heavy repositories, or a small internal Composer script that installs native Git hooks. The right choice depends on your operating system support, Composer 2 compatibility, monorepo needs, and team familiarity. Whichever option you choose, keep hook runtime short and avoid replacing CI enforcement.
- How should I test and roll out the package in a Laravel team?
- Pilot it in one representative Laravel repository, pin the package version, and configure a minimal pre-commit hook that calls an existing Composer script. Test a fresh clone, Composer install with and without scripts, missing-hook recovery, and the documented bypass command against your current CI pipeline. Expand only after measuring hook installation rate, pre-commit runtime, bypass frequency, and reduction in CI-only failures.
- Does it support monorepos, Git worktrees, Windows, or WSL?
- These environments can expose path, hook-location, and Git version differences, especially with an older package that is no longer maintained. Test the package in each developer environment your team supports and document any workarounds before standardizing it. If hook installation or execution is unreliable, use a maintained alternative or keep the hook setup simple and local to each repository.