- How do I install mnabialek/laravel-version?
- Install it with composer require mnabialek/laravel-version. On Laravel 11 and 12 the service provider is auto-discovered, so no manual registration is required. Publish the config file with php artisan vendor:publish if you want to change where the version number is read from.
- Does this package work with Lumen?
- Yes. Detecting whether the app is Laravel or Lumen and returning the correct version is the package's core purpose. Because Lumen does not support package auto-discovery, you register the service provider manually in bootstrap/app.php with $app->register(...).
- How do I show the version number in a Blade template?
- The package ships a Blade directive plus helper functions, so you can output the version directly in a view. A common pattern is placing the directive in your layout footer or an internal about page. Resolved values are cached, so repeated calls in hot paths stay cheap.
- How do I display my own application version instead of the framework version?
- The package can read the version from your composer.json, from a config value, or from a custom version file you point it at. Set the preferred source in the published config, then use the helper or Blade directive in views, API responses, or health checks.
- Which Laravel versions does mnabialek/laravel-version support?
- Release 1.0.9 widened framework compatibility to include Laravel 12, so pin ^1.0.9 if you are running Laravel 11 or 12. Laravel 12 requires PHP 8.2 or newer, so environments still on PHP 8.1 must upgrade first. Before upgrading a Laravel 10 app, confirm in the package's composer.json that older framework constraints were not dropped in the same release.
- Does the package cache the version, and how do I refresh it after a deploy?
- Yes, the resolved version is cached so the package does not re-read composer.json or a custom version file on every request. That makes it safe to call in layouts, middleware-free endpoints, and API responses. Clear your application cache after bumping the app version so the new value is picked up.
- Can I use it in an API health check or version endpoint?
- Yes. Return the helper's output in a JSON response from a route or controller to expose the deployed build number. This is handy for confirming which release is live after a deployment. Because the value is cached, the endpoint stays lightweight.
- Where does the package read the version from by default?
- By default it reads the version declared in your project's composer.json, and you can override the source in config to use a config key or a custom file. That flexibility helps when your CI pipeline injects a git tag or build number into a VERSION file rather than composer.json.
- Is this package safe to add to a production Laravel application?
- It is a small utility library with no middleware, queue workers, or database dependencies, so the blast radius of an upgrade is minimal. Version 1.0.9 is a patch release whose stated change is adding Laravel 12 support. Install it on a branch and run your test suite to confirm the constraint widening did not drop support for your current framework version.
- What are the alternatives if I only need the Laravel framework version?
- You can call app()->version() for the framework version, or use Composer\InstalledVersions to read a package version at runtime. For your own app version you can hardcode a config value or parse composer.json yourself. This package mainly saves that plumbing, adds Laravel versus Lumen detection, and gives you helper and Blade access with caching.