Weave Code
Dev Tools Laravel Package
open-telemetry/dev-tools
Shared development tooling for OpenTelemetry PHP: coding-standard, static-analysis, and CI configurations that keep contributions consistent across the ecosystem. Add it as a dev dependency to align packages with project conventions.
OpenTelemetry PHP Dev Tools provides the shared development tooling used across the OpenTelemetry PHP ecosystem. It packages reusable configurations and scripts so maintainers can apply consistent coding standards, static analysis, and quality checks without duplicating setup in every repository.
- Centralized PHP-CS-Fixer configuration for uniform code style
- Shared PHPStan rules for consistent static analysis
- Prebuilt scripts to run linting and quality checks quickly
- Easy integration into CI pipelines for repeatable automated validation
- Keeps tooling versions and rules aligned across packages
Frequently asked questions about Dev Tools
- What is open-telemetry/dev-tools used for?
- open-telemetry/dev-tools is a development-time companion package for OpenTelemetry PHP projects. It bundles shared Composer scripts, PHP-CS-Fixer rulesets, PHPStan or Psalm configuration, CI helper scripts, and test utilities such as in-memory exporters and mock context storage. It is intended for teams building or maintaining OpenTelemetry instrumentation, exporters, or processors, not for typical Laravel applications that only consume the OpenTelemetry SDK.
- Is open-telemetry/dev-tools required in production for a Laravel app?
- No. It should be installed with require-dev and must never be part of your production deployment artifact. The runtime OpenTelemetry value in a Laravel application comes from packages such as open-telemetry/sdk, open-telemetry/exporter-otlp, and framework auto-instrumentation, not from this dev-tools package.
- How do I install open-telemetry/dev-tools in a Laravel project?
- You install it mechanically with composer require --dev open-telemetry/dev-tools. The more important question is whether it is additive or substitutive for your existing QA stack. Most Laravel teams should treat it as reference material and cherry-pick rules into their own Pint and PHPStan configuration rather than adding a direct dependency.
- Does open-telemetry/dev-tools work with Laravel Pint and Larastan?
- It can overlap significantly with Pint and Larastan. Pint vendors its own PHP-CS-Fixer and locks a specific major version, while OpenTelemetry's rulesets are written against its own PHP-CS-Fixer and PHPStan versions. Layering them can create duplicate fixers or version pin conflicts, so the low-risk approach is to copy relevant rules into pint.json and phpstan.neon instead of depending on the package directly.
- Which Laravel versions are supported by open-telemetry/dev-tools?
- This package does not target Laravel framework versions directly; it is development tooling tied to PHP versions and static-analysis tool majors used by the OpenTelemetry PHP monorepo. Your Laravel version support is determined by the OpenTelemetry SDK and auto-instrumentation packages you actually run. Check the package's PHP constraints and CI assumptions before adding it to a Laravel project.
- Can I use open-telemetry/dev-tools test helpers in my Laravel test suite?
- Possibly, but only if the current release ships executable PHP test doubles such as InMemoryExporter-style helpers or mock context storage that you would actually call from your tests. Those are the only plausible value points for an application team. Inspect the release contents first, because much of the package is configuration rather than callable test code.
- Why does open-telemetry/dev-tools have zero stars and dependents?
- It is almost certainly a read-only subtree split of the open-telemetry/opentelemetry-php monorepo. The real activity, issues, and star count live on the parent repository, which is normal for PHP monorepos. That means issue triage happens upstream and release cadence follows the parent project's tooling needs rather than consumer demand.
- What are alternatives to open-telemetry/dev-tools for Laravel code quality?
- For a typical Laravel application, the practical alternatives are Pint for coding standards, Larastan for Laravel-aware static analysis, and Pest or PHPUnit for testing. You can also read OpenTelemetry's rulesets and PHPStan configuration and cherry-pick individual rules into your existing setup. Direct use of open-telemetry/dev-tools is mainly justified when you maintain reusable OpenTelemetry instrumentation code.
- Is open-telemetry/dev-tools safe to add to a Laravel CI pipeline?
- Licensing risk is low because it is Apache-2.0 and CNCF-backed, but version coupling is the main CI concern. Your pipeline becomes transitively pinned to the PHP-CS-Fixer and PHPStan majors that OpenTelemetry targets, which can collide with Laravel, Pint, and Larastan upgrade paths. It may also assume GitHub Actions or Docker-based make targets that you would need to port to GitLab or Buildkite.
- When should a Laravel team depend on open-telemetry/dev-tools directly?
- Depend on it directly only when you are building or maintaining OpenTelemetry PHP instrumentation, custom exporters, or processors that must conform to upstream CI conventions. It is a poor fit as a general-purpose QA dependency for a product Laravel application. If you are merely consuming OpenTelemetry in a Laravel app, use the SDK and exporter packages and leave this package out of your Composer dependencies.
Weaver
How can I help you explore Laravel packages today?