- What is kylekatarnls/multi-tester used for?
- multi-tester is a Composer dev dependency and CLI that runs the test suites of dependent projects against your current package code. It swaps your working copy into each target project's vendor directory, then runs that project's own tests. It is useful for interconnected Composer packages where a small change can break a downstream project even when your own coverage is good.
- How do I install multi-tester in a Laravel package?
- Install it with composer require kylekatarnls/multi-tester --dev in the Laravel package or Composer project you want to test. Your project needs a composer.json at the root with a name property because that name is used when replacing your code in dependent projects. After installation, run vendor/bin/multi-tester from your project.
- Does multi-tester work with Laravel or only framework-agnostic Composer packages?
- multi-tester is framework-agnostic rather than a Laravel-specific package, so it has no Laravel version constraints of its own. It can target a Laravel application or package as long as the target is a Composer project with a name and a runnable test script. Your CI still needs PHP 7.2 or newer, Composer, and Git available.
- How does multi-tester replace my package in dependent projects' vendor directories?
- For each configured target, multi-tester clones the project, runs composer install, and replaces vendor/<your-package> with a symlink or copy of your working tree. It then runs the target's configured script. This means the target's tests execute against your local changes rather than the published version.
- How do I configure .multi-tester.yml with the --add option?
- Run vendor/bin/multi-tester --add=vendor/package to scaffold a .multi-tester.yml file. The config lists target packages, optional version constraints, and the install and script commands to run. Review and pin each entry before relying on it in CI.
- Can I test multiple versions of the same dependent package?
- Yes. The config supports inline entries such as symfony/symfony:5.4.* so you can test the same dependent package at different versions. This is useful for support-matrix checks. Pin explicit versions for every target to avoid flaky runs from HEAD or latest stable changes.
- Does multi-tester support Travis CI, and what about GitHub Actions?
- Yes, multi-tester is Travis CI friendly and can harvest Travis commands from a target project's .travis.yml. That helps when testing open-source downstream projects you do not control. For GitHub Actions or other CI systems, invoke vendor/bin/multi-tester as a normal CI step.
- What PHP and Composer versions does multi-tester require?
- multi-tester requires PHP 7.2 or newer, Composer, and Git, and the configured target directory must contain a composer.json with a name. Version 2.6.0 dropped PHP 7.1 support. Your CI also needs outbound access to Packagist and GitHub for cloning and dependency installation.
- Is multi-tester safe for production CI, and what are the risks?
- Treat changes to .multi-tester.yml as CI privilege changes because the tool clones repositories and executes arbitrary install and script shell commands. Pin every target version and review the config to reduce supply-chain and non-determinism risk. The vendor-directory swap can also interact with Composer plugins, path repositories, replace keys, and autoloader state, so verify that a green run is meaningful.
- What are the alternatives to multi-tester and is it maintained?
- Alternatives include Composer path repositories, monorepo test orchestration, and CI matrix jobs that install your branch into each downstream project. multi-tester is a small single-maintainer tool with low adoption, so plan to read the source and fork it if needed. Before adopting it, confirm the named downstream projects pass their own suites manually and pin their versions.