Laravel App Laravel Package

Getting Started

What it actually buys you. andrey-helldar/laravel-app is a thin application-metadata layer: one place to read the app's name, version and environment, plus a handful of runtime/path predicates, wired through Laravel's container and auto-discovery. It is not a framework extension and not a subsystem — think "small facade over things you'd otherwise write as config('app.name'), App::environment(), app()->isLocal(), base_path()".

Install and confirm discovery.

composer require andrey-helldar/laravel-app
php artisan package:discover   # normally unnecessary; run it if you cached packages

There is no manual provider registration step — the provider is auto-discovered via composer.json extra.laravel.providers. If the package appears in composer show but its API is not resolvable, discovery is the first thing to check, not your own code.

Where to look first. Documentation is minimal and the package is archived, so the source is the contract. Read, in this order:

1. vendor/andrey-helldar/laravel-app/composer.json — gives you the real PHP and illuminate/* constraints. This is the single most important file for deciding whether you can use it at all.
2. vendor/andrey-helldar/laravel-app/src/ — the service provider, the facade/class it binds, and any config file. Note the exact binding key and facade alias; the method surface is small enough to read in one sitting.
3. vendor/andrey-helldar/laravel-app/config/ — whether metadata is config-driven or derived (e.g. from composer.json).

First use case. Take the most repetitive snippet in your app — a footer/email/health endpoint that renders config('app.name') and a version string, or an if (app()->environment('local', 'staging')) guard scattered across providers — and replace it with one injected dependency. That single refactor tells you whether the package's naming and semantics match your codebase; if it doesn't, you've lost ten minutes, not a sprint.

Implementation Patterns

Prefer constructor injection over the facade. A small metadata object is exactly the kind of thing that should be injected, because it makes the dependency visible and swappable in tests:

use AndreyHelldar\LaravelApp\...; // confirm the concrete class in src/

final class ReleaseController
{
    public function __construct(private AppMetadata $app) {}

    public function __invoke(): array
    {
        return [
            'name'    => $this->app->name(),
            'version' => $this->app->version(),
            'env'     => $this->app->environment(),
        ];
    }
}

Facades are fine in Blade and in service providers, where resolution-order matters and constructor injection is awkward. Use one style per codebase — mixing container resolution and facade calls makes it hard to tell later whether you're talking to the package or to Laravel's own App facade, which is a real source of confusion given the name collision.

Wrap it before you spread it. Because the package is archived, treat its API as a third-party detail you may have to replace. Bind your own interface and delegate:

// app/Contracts/AppInfo.php
interface AppInfo { public function name(): string; public function version(): ?string; public function isProduction(): bool; }

// app/Providers/AppServiceProvider.php
$this->app->bind(AppInfo::class, fn ($app) => new class($app->make(/* package class */)) implements AppInfo {
    // delegate to the package here
});

You get the package's conveniences today and a one-file migration path later. This is the highest-leverage pattern with an abandoned dependency: isolate it at one seam, then never import it directly anywhere else.

Use it where Laravel's own calls are verbose or duplicated. Good candidates:

• Health/readiness endpoints and /about-style output — name, version, environment in one payload.
• Email templates and PDF headers — a single $app->name() instead of hardcoded strings.
• Artisan commands reporting build/version to logs.
• Deployment smoke tests asserting the running environment is what you think it is.

Poor candidates: request-scoped logic, anything in a hot loop, and any place where Laravel's native helper already reads clearly.

Config-first metadata. If the package exposes a publishable config, publish it and set version/name there rather than hardcoding constants in code:

php artisan vendor:publish --provider="AndreyHelldar\LaravelApp\...ServiceProvider"

Then config:cache in production and verify the resolved values via php artisan tinker — cached config is the usual reason metadata "changes" between local and prod.

Testing. Because the surface goes through the container, you can swap it in setUp() with a fake returning fixed name/version/environment. Assert on your AppInfo interface, not the package class, so tests survive a future replacement. For assertions about environment-dependent branching, override the binding rather than mutating APP_ENV.

Gotchas and Tips

It is archived — budget for that explicitly. Last release was 2022-02-14. Check the illuminate/* constraint in composer.json against your Laravel version before anything else; on current Laravel the constraint will likely conflict, and there will be no patch if it does. If you're on a recent framework, the honest recommendation is to skip the dependency and implement the three or four accessors yourself — the package is a convenience, not a capability. Adopt it only where the constraint resolves cleanly, and only behind the wrapper described above.

App is a crowded name. The package's facade alias can collide conceptually (and occasionally literally) with Laravel's own App facade and app() helper. Symptoms: "method does not exist" errors that look like a version mismatch but are actually alias resolution. Use fully-qualified imports, and check config/app.php aliases and the package's extra.laravel.aliases for the exact registered name.

Environment reads must go through config, not env(). If the package reads env('APP_ENV') or similar directly, values vanish once config:cache runs. Confirm the source uses config(); if it doesn't, treat cached-config deployments as a separate test case, not an afterthought.

Metadata drift between composer.json and config. If version is derived from Composer, it can differ from a config value or a git tag. Pick one source of truth (usually a CI-injected config value or the tag), and note in the readme which one wins — this bites during incident triage when the reported version doesn't match the deployed commit.

Auto-discovery caching. After composer require, composer update, or a deploy with composer install --no-dev, run php artisan package:discover and php artisan config:clear if the API is unreachable. bootstrap/cache/packages.php and services.php going stale is the classic failure mode in containerized deploys with a baked image.

Don't let path helpers drift from Laravel's. If the package offers path/is* checks, prefer base_path(), app_path(), storage_path() and app()->runningInConsole() unless the package's variant adds something real. Duplicated path logic is a maintenance tax with no upside, and these are precisely the functions Laravel has kept stable.

Debugging checklist. composer show andrey-helldar/laravel-app (installed version + constraints) → php artisan package:discover -v → php artisan tinker and resolve the class by hand → read the provider's register()/boot() to see the binding key. If tinker resolves it but your class doesn't, you're almost certainly type-hinting an interface the package doesn't bind — bind it yourself in a provider.

Extension points are minimal, and that's fine. The realistic ones are: publish and edit the config, rebind the concrete class in your own provider, and wrap it behind your own interface. There is no event system or driver architecture to hook into here, so don't design around one. If you find yourself needing more than a rebind, that's the signal to drop the package and write the ~30 lines yourself.