Weave Code
Dev Pack Laravel Package
irstea/dev-pack
irstea/dev-pack is a Laravel/PHP development package that bundles convenient tooling, helpers, and workflow utilities for local development. It aims to streamline common setup and debugging tasks so teams can keep projects lean and focused on building features.
Méta-package qui regroupe les différents outils que nous utilisons en développement.
Frequently asked questions about Dev Pack
- What is irstea/dev-pack and what does it actually include?
- irstea/dev-pack is a Composer meta-package for Laravel and PHP development that pins a curated set of opinionated QA and workflow tools. It is essentially a composer.json that pulls in other packages, with little or no runtime code of its own. The overview promises zero-config defaults, Artisan-friendly commands, publishable configuration, and lightweight helpers. To see the exact packages and version constraints, inspect its composer.json and the resulting composer.lock.
- How do I install irstea/dev-pack in a Laravel project?
- Register the GitLab repository https://gitlab.irstea.fr/pole-is/tools/php-dev-pack.git as a Composer VCS repository, authenticate with GitLab credentials, then run composer require --dev irstea/dev-pack. On developer machines a personal access token works; in CI use a read-only deploy token. Installation itself is trivial, but every machine and runner needs credentials before Composer can resolve the package. If a private Packagist or Satis proxy is available, prefer that over direct VCS access.
- Which Laravel and PHP versions does irstea/dev-pack support?
- The available metadata does not state supported Laravel or PHP versions, so you must confirm this with the maintainers or by reading its composer.json constraints. Because it pins a QA toolchain, its PHP requirement may be stricter than your applications' requirement. Check that the pack's PHP and tool versions overlap your CI matrix before adopting it. If your apps span multiple Laravel majors, verify each one independently in a sandbox.
- Should irstea/dev-pack go in require or require-dev?
- It must go in require-dev. It is a development toolchain meta-package, not application runtime code, and promoting it to production require can bloat your deployment artifact and break composer install --no-dev builds. Keeping it in require-dev also prevents production environments from inheriting irrelevant pinned constraints. Verify after installation that your production lock file does not pull the pack or its tools.
- Do I need GitLab credentials or a private Packagist to install irstea/dev-pack?
- Yes, unless your organization proxies it. The package lives on gitlab.irstea.fr rather than Packagist, so Composer resolves it over Git and needs authentication. Use a personal access token locally and a read-only deploy token in CI. Distributing those credentials to every laptop and runner is the real workstream; without a private Packagist or Satis mirror, resolution is slower and more brittle than normal Packagist installs.
- What happens if the versions pinned by irstea/dev-pack conflict with my app's tools?
- If the pack pins a tool major that differs from your application's, Composer will block the install or force an unwanted downgrade or upgrade. The only remedies are an upstream constraint change, a local fork, or excluding the pack. Before adopting it, compute the union and intersection of require-dev across your repositories and quantify any conflicts. Pinning risk is the main technical risk of a meta-package like this.
- Does irstea/dev-pack run Composer plugins or scripts during installation?
- The public metadata does not confirm whether it declares Composer plugins, scripts, or config blocks. Dev dependencies still install and execute code, so review its composer.json before allowing anything. Composer 2.2 and later will block undeclared plugins unless you explicitly allow them via allow-plugins. Decide deliberately which plugins you permit rather than allowing them by default.
- Can I customize irstea/dev-pack configuration without forking it?
- The overview advertises publishable configuration, which usually means you can publish its config files and override defaults per project. It may also ship rulesets such as phpstan.neon or .php-cs-fixer.dist.php that your project can extend or replace. Confirm exactly which files are publishable and whether project-level overrides take precedence. If the pinned versions are the problem, configuration overrides will not solve that and a fork may be required.
- Is irstea/dev-pack suitable for production or non-Laravel PHP projects?
- No, it is intended for local development and CI quality checks, not production runtime. It is also a poor fit for non-Laravel PHP services because they would inherit Laravel-oriented constraints and tooling they do not need. It fits best in a Laravel estate with multiple applications that want one shared quality gate. Services that legitimately need different tool majors should stay outside the pack.
- Is irstea/dev-pack actively maintained, and what are the alternatives?
- There is no public signal such as Packagist presence, stars, dependents, or a stated release cadence, so treat maintenance as an open question. Ask the maintainers who owns it, whether it is semver-tagged, and how major upgrades are handled. If it is abandoned, the exit path is replacing it with your own explicit require-dev list or an internal Composer metapackage. Because it is a thin meta-package, forking or recreating it is relatively low effort.
Weaver
How can I help you explore Laravel packages today?