# laravel-decomposer: a diagnostics page for Laravel apps and their packages

> Laravel Decomposer is a package that renders a single route listing every installed package, its dependency versions, and the Laravel and server environment behind them, and it can emit the same information as markdown, an array or JSON. It exists to end the support thread that begins with a user saying they are on an older PHP version.

**lubusIN/laravel-decomposer** — Laravel package to decompose your installed packages, their dependencies, your app & server environment

- Repository: https://github.com/lubusIN/laravel-decomposer
- Stars: 641 · Forks: 42
- Language: Blade
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/lubusin-laravel-decomposer

## One route produces a package list, dependency versions and server details

Laravel Decomposer decomposes and lists all the installed packages and their dependencies along with the Laravel and server environment details the app is running in. The README states it plainly, and the rest of the project is variations on that one page.

The output has three parts. The installed packages with their dependency trees, the Laravel and server environment details, and a check of whether the pre-configurations and extensions Laravel asks for are actually applied and loaded. The third part is the one that earns its place in a support thread, because a missing extension or an unmet configuration requirement is a common cause of an app that works on one machine and not another.

The README also describes a migration from a Bootstrap 3 CDN and jQuery frontend to Tailwind CSS and Alpine.js, and the repository backs that up: the top level contains `tailwind.config.js` and `vite.config.mjs`, and the `package.json` lists `tailwindcss` at `^4.1.4`, `alpinejs` at `^3.14.9`, `vite` at `^6.3.2` and `autoprefixer` at `^10.4.21` as dev dependencies, with `vite` handling the build. So the front end is now a compiled asset pipeline rather than a CDN dependency, which matters in a package that gets installed into other people's applications.

The `package.json` also carries a `test` script that echoes an error and exits, so there is no test suite in the JavaScript layer. The package's own `composer.json` is the part that matters for a Laravel user, and the README's requirement list is the compatibility contract.

## Installation is three artisan commands and one route

The install path is short and explicit. First the package:

```bash
composer require lubusin/laravel-decomposer
```

Then the config, which is optional, and the assets:

```bash
php artisan vendor:publish --tag=DecomposerConfig
```

```bash
php artisan vendor:publish --tag=DecomposerAssets --force
```

The config publish step is the one with a decision in it. After publishing, you update `config/decomposer.php` and set `exclude_folders` to control which folders are ignored while calculating `app_size`. So the application size figure depends on a setting you are expected to tune, and the default is whatever the package ships. For a repository with a large `storage` directory or vendored assets, that number is otherwise going to be misleading.

Finally you add the route in `routes/web.php`:

```php
use Lubusin\Decomposer\Controllers\DecomposerController;

Route::get('decompose', [DecomposerController::class, 'index']);
```

And then you visit http://yourapp/decompose, or whatever path you configured. The route name and the controller are both under the `Lubusin\Decomposer` namespace, which is the older PSR-4 style for a package that supports Laravel 6 through 13.

The final step is the one to think about. This route is, by design, an unauthenticated view of your dependency graph and your server environment. The README's own use case is a non-technical user generating a system report and sending it over, so the route is built to be shared. That is fine on a staging box and a problem in production.

## The report is available as markdown, an array and JSON

The most consequential feature in the project is not the web page. It is that the same report can be produced programmatically.

The README says Decomposer generates a markdown report from those details, and that it allows you to generate the same report as an array and as JSON anywhere in your code. The wiki pages listed under Usage confirm the three shapes: Get Decomposer report as markdown, Get Decomposer report as an array, and Get Decomposer report as JSON. The Roadmap also records that report access via code shipped in v1.1.

That capability changes what the package is for. A page a user screenshots is a support artifact. A report you can call from an API endpoint, attach to a bug report, or diff against a stored baseline is a diagnostic you can automate. The repository even ships a `report.md` at the top level, which is the committed output of a run.

The third shape is the extension point. The Roadmap records that allowing users and other packages to add their own stats shipped in v1.2, and the wiki has a page titled Add your own extra stats for your package or app. For a package author, that means the report can carry the specific facts only you know, such as which version of your own package is installed, rather than making the user type it into an issue.

The remaining Roadmap items are worth knowing as well, because they tell you what the tool does not do yet. A config file to control what appears in the view is listed as pending. Checking for updates of the installed packages is pending. Comparing the same dependency versions across packages and warning about conflicts is pending, with a note that it can already be done manually because the search results are highlighted. The UI work is also listed as unfinished.

## The stated use case is a support request that begins with a missing fact

The Features section is written around one scenario, and it is worth reading closely because it explains the design.

The primary use is a non-technical client or user of your Laravel app, or a non-experienced developer who does not use the CLI, generating the system report and sending it over so you know the entire details of the environment. The second use is for package and Laravel app developers collecting information from the users reporting issues, since the report gives complete information about the environment the issue was raised in.

The troubleshooting example is the sharpest. The README says it cuts down troubleshooting time, and gives the case where, after trying all possible solutions, the user says they forgot to mention they are on PHP 4, with Decomposer acting as a precaution and removing the dependency of querying the user for every single thing.

There is a second, less obvious use that is arguably more valuable for maintainers. The README describes a scenario where one package uses illuminate/support v5.1 and another uses illuminate/support v5.3, and says that getting these facts quickly by hitting a route makes you aware of possible instability and conflicts so you can report that to the respective package developer. That is a dependency conflict audit in a single page, and it applies to your own application, not just to a support ticket.

The limitation of all of this is the same in every case. The report is a snapshot of the environment as it is right now, so it describes the state after the breakage, not the state that caused it.

## Composer and the ecosystem report instead of a bespoke debug endpoint

There are two other ways to answer the question this package answers, and both are stronger in a different direction.

The first is the Composer command line. Composer's own diagnostics tell you what is installed, what depends on what, and what the platform requirements of your lockfile are, and you can script it. The difference in approach is that Composer's view is of the dependency graph as declared, while Decomposer's view also includes the runtime environment: the server, the loaded extensions, and whether Laravel's expected configuration is present. On a machine where the problem is a missing extension rather than a version conflict, Composer will not tell you what you need.

The second is a purpose-built APM or error reporting service, which captures the environment at the moment of failure rather than when somebody thinks to go and look for it. That is strictly better for the case of an app that broke and nobody noticed for two days. The trade is that it is a service you run, it is heavier than a package, and it is aimed at errors rather than at the ambient state of the system.

There is also the option of writing your own diagnostic route, which for a single application you own may be twenty minutes of work and gives you exactly the fields you care about. Decomposer earns its place when you cannot install code into the user's application, or when the application is not yours and you need a standard answer rather than a bespoke one.

Whichever route you pick, the report is a snapshot and the diff between two snapshots is the more useful artifact. Decomposer can produce JSON, so comparing two reports is a script away, and that comparison catches the drift that a single report never will.

## Licence, release line and the PHP floor

The package is MIT licensed, with the terms in `LICENSE.txt` at the repository root, and the Packagist page and a licence badge in the README both point at it. That is a permissive licence with no obligation on downstream users beyond retaining the notice, and it is not legal advice.

The compatibility contract is stated in two lines. The requirement is PHP 7.1.3 or newer, and the supported versions are Laravel 6.x through 13.x. That range is wide, and it is wide because the package is mostly a read-only reporter with one controller, so there is little in it that has to change between major Laravel versions.

The release history is recent and slow-moving. v1.4 was tagged on 2026-03-19, v1.3.1 on 2025-06-11 and v1.3 on 2025-05-14, and the last push was on 2026-04-18. The repository is not archived.

The README also states a security reporting path: if you discover a security vulnerability within Laravel, send an email to info@lubus.in, and all security vulnerabilities will be promptly addressed. That is worth taking seriously here, because the most obvious security question about this package is the exposed route, and the answer is on you rather than on the maintainer. The route is registered by you in `routes/web.php`, so removing it, or putting it behind middleware, is part of installing the package rather than an afterthought.

## Conclusion

Adopt laravel-decomposer when you support Laravel applications you do not control and you need an environment report faster than a questionnaire, or when you maintain a package and want users to hand you a complete dependency picture. Do not leave the route mounted in production, since it exposes your package list, dependency versions and server details to anyone who can reach it. Verify first that your Laravel version falls in the documented range of 6.x through 13.x and that the PHP requirement of 7.1.3 or newer is met, and check the `exclude_folders` setting in the published config before trusting the app size figure.

## FAQ

### How do I install Laravel Decomposer?

Run `composer require lubusin/laravel-decomposer`, then optionally publish the config with `php artisan vendor:publish --tag=DecomposerConfig` and the assets with `php artisan vendor:publish --tag=DecomposerAssets --force`. Finally add the route that mounts `Lubusin\Decomposer\Controllers\DecomposerController` and visit your app at that path.

### What does the Laravel Decomposer report contain?

The installed packages and their dependencies, the Laravel and server environment details, and a check of whether the configurations and extensions Laravel expects are applied and loaded. The same report is available as markdown, as an array and as JSON.

### Which Laravel and PHP versions does Laravel Decomposer support?

The README lists Laravel 6.x through 13.x as supported and PHP 7.1.3 or newer as the requirement. The package is MIT licensed and the terms are in the LICENSE.txt file at the repository root.

### Is the Laravel Decomposer route safe to leave enabled in production?

The route is registered by you in routes/web.php and shows your package list, dependency versions and server environment to anyone who reaches it. The README's intended use is for a user to generate a report and send it for support, so restrict the route with middleware or remove it outside of a support session.

### Can I add my own data to the Laravel Decomposer report?

Yes. The README states that users and other packages can add their own extra stats specific for their package or your app, a feature the roadmap records as released in v1.2, and the wiki has a page on adding your own extra stats.

## Sources

- [Issues](https://github.com/lubusIN/laravel-decomposer/issues)
- [License: MIT](https://github.com/lubusIN/laravel-decomposer/blob/master/LICENSE)
- [lubusIN/laravel-decomposer on GitHub](https://github.com/lubusIN/laravel-decomposer)
- [README](https://github.com/lubusIN/laravel-decomposer/blob/master/README.md)
- [Releases](https://github.com/lubusIN/laravel-decomposer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lubusin-laravel-decomposer