- How do I install pragmarx/version in a Laravel app?
- Install it with Composer using composer require pragmarx/version; the service provider and facade are registered through Laravel package auto-discovery, so you normally do not need to edit config/app.php. After installing, publish the package config if you want to customize where the version value comes from. Verify the Laravel and PHP constraints declared in the package's composer.json before committing, since the package predates several framework majors.
- Which Laravel and PHP versions does pragmarx/version support?
- The real answer is whatever is declared in composer.json and, more importantly, covered by its test suite. Because this is a small single-maintainer utility with a long release history, its constraints often lag behind the newest Laravel majors. Install it on a branch and run your own tests on your exact Laravel and PHP versions before adopting it. If the constraint blocks your stack, an internal helper is a low-cost alternative.
- How do I display the application version in a Blade template?
- This is the package's core use case: read the version through the facade or a config value and output it in the template, and many setups use the provided Blade directive where it exists in your installed release. Check the README for the exact directive name and facade method for your version. Rendering a cached version string in a footer costs nothing beyond a config lookup at boot.
- Can I expose the app version through an API endpoint?
- Yes, but make it a deliberate decision: a public version endpoint is a fingerprinting aid that tells an attacker which release to target. The package does not register routes for you, so you own the surface. Wrap the facade call in your own route and restrict access when the consumer is internal, such as support, observability, or ops tooling. For public APIs, consider returning a coarse build identifier rather than a precise version.
- Does pragmarx/version work with config caching and read-only containers?
- Reading the version works fine with cached config because it is just a value resolved at boot. The risk is any feature that writes or bumps a version file at runtime: immutable container images and read-only filesystems reject those writes, and cached config will not pick up the new value without a rebuild. If your pipeline writes the version during CI instead, the package degrades to a read-only resolver, which is the safer pattern.
- Is pragmarx/version still maintained?
- It is a stable, low-churn utility with a single maintainer, so thin activity is by design rather than proof of abandonment. Check the release history and issue responsiveness over the last 24 months before depending on it. Because the blast radius is tiny, a leaf dependency with no persistence layer, the cost of removing it later is minimal either way.
- Should I use pragmarx/version or write my own internal helper?
- If all you need is to surface a build-time variable, an internal accessor of roughly twenty lines gives the same result with no dependency and no second source of truth. The package earns its place when you actually use its bumping and formatting workflows or want the conventional facade and Blade directive out of the box. Weigh that against the compatibility and supply-chain review any third-party package adds.
- How do I keep the reported version in sync with git tags or a CI build number?
- Pick one canonical source, usually a git tag or a CI-injected APP_VERSION environment variable, and have the package read that value instead of storing its own. Otherwise the version your app reports will drift from what was actually deployed, which is a genuine hazard during incident triage. Writing the version file at build time in CI keeps the runtime read-only and the two sources consistent.
- Is pragmarx/version safe to add to a production Laravel application?
- The package is small, MIT licensed, and has no domain model or persistence beyond an optional version file, so the attack surface it adds is minimal. The realistic risks are operational rather than security related: compatibility drift on newer Laravel majors, file writes failing in immutable containers, and information disclosure if you publish a public version endpoint. Run your normal dependency and license scanning as you would for any Composer package.
- How do I test that the version is reported correctly?
- Assert against the same source of truth your deployment uses: set the version value in the test environment and verify that the facade call and any Blade output return it. Because the value resolves through config, you can swap it in tests without touching the filesystem. If you expose an endpoint, add a feature test for the response shape and status code rather than asserting a literal version string.