Widget Installer Laravel Package

Getting Started

Before writing a line of integration code, calibrate expectations. toro/widget-installer has 0 stars, 0 dependents, and its last release was 2017-01-06. That means it was almost certainly built for Laravel 5.x and PHP 5.6/7.0. Treat it as legacy scaffolding or a reference implementation, not a dependency you casually composer require into a modern Laravel app.

First place to look, in order:

1. composer.json in the repo — this is the whole assessment. Check:
   • require constraints on illuminate/support, illuminate/console, php
   • The PSR-4 autoload namespace (likely something like Toro\WidgetInstaller\)
   • Whether it declares extra.laravel.providers (Laravel 5.5+ package discovery) or predates it
2. src/ — look for a *ServiceProvider.php and any Console/Commands/ directory. Given the name, expect one or more Artisan commands that copy/scaffold "widget" files into the host application.
3. config/ — if present, it will tell you the package's mental model: source paths, target paths, namespaces.
4. README.md — read it last. An unmaintained 2017 package's README is often aspirational; the code is the truth.

Minimal evaluation path (do this in a throwaway environment matched to the package's era):

# Throwaway Laravel 5.5 / PHP 7.0 app, NOT your production app
composer create-project laravel/laravel:5.5 scratch
cd scratch
composer require toro/widget-installer --dev

If Packagist no longer serves it, add the GitHub repo as a VCS repository and require it with an explicit constraint, or better: git clone it next to your app and add a path repository.

Then locate and run the installer:

php artisan list | grep -i widget
# If no package discovery (pre-5.5), register manually in config/app.php:
# Toro\WidgetInstaller\WidgetInstallerServiceProvider::class,
php artisan vendor:publish

First use case: install exactly one widget and git status the result. The entire question of whether this package is useful to you is answered by "what files did it write, and would I have written those myself in 10 minutes?" For an installer package with no adoption, the honest answer is frequently yes.

Implementation Patterns

If you decide to use it, treat it as a one-shot build/ scaffold step, not a runtime dependency.

Config-first wiring. Publish the config before invoking any command, and read it in full. Installer packages encode their assumptions there:

php artisan vendor:publish --provider="Toro\WidgetInstaller\WidgetInstallerServiceProvider" --tag=config

Expect keys for source path, destination path, and possibly a namespace or stub set. Change them explicitly rather than relying on defaults — defaults that assume base_path('widgets') will silently misbehave on custom directory structures.

Wrap the Artisan command, don't call it scattered around. If the package exposes something like widget:install {name}, invoke it from a single place — a Composer script, a deployment task, or your own thin Artisan command — so the invocation is auditable:

"scripts": {
    "post-create-project-cmd": [
        "@php artisan widget:install default"
    ]
}

Prefer --dev + vendor the output. The strongest pattern for an abandoned installer is:

1. Run it once in a scratch branch.
2. Commit the generated widget code into app/ or resources/.
3. Remove the package from composer.json.

You get the scaffolding benefit without inheriting an unmaintained transitive dependency tree. This also removes an entire class of "the installer changed and my output changed" surprises.

Isolate from your domain code. Never let application services reference the installer's classes directly. If the package registers bindings in the container, resolve through your own interface so that removing the package is a one-file change.

Test the generation, not the package. Snapshot the produced file list and contents:

public function test_widget_scaffold_is_stable(): void
{
    $this->artisan('widget:install', ['name' => 'example'])->assertExitCode(0);
    $this->assertFileExists(resource_path('views/widgets/example.blade.php'));
}

Run it in CI on a clean checkout — installers are exactly the class of package that works locally and fails on a fresh machine due to permissions, missing directories, or path assumptions.

Integration tips specific to 2017-era Laravel:

• Pin the exact version ("toro/widget-installer": "1.0.0", no caret) if it has any transitive deps at all.
• If it predates package discovery, register the provider in config/app.php under providers for local/dev only, gated by an env check.
• Match the illuminate/* major version to your app; a ^5.1 constraint will simply refuse to install on Laravel 10/11, which is arguably the correct outcome.

Gotchas and Tips

It is abandoned, and that is the headline. No security patches, no PHP 8 compatibility, no Laravel 6+ support. Before adopting anything with this profile, run composer why-not toro/widget-installer and composer audit in the scratch project to see what it drags in. If the only reason it won't install is the illuminate/support constraint and the code is trivial, that's a signal to fork and vendor rather than force it with --ignore-platform-reqs.

--ignore-platform-reqs is a trap here. It will get you past the version guard and then fail at runtime on removed helpers, array_get/str_* functions, or deprecated Illuminate\Support APIs. Only acceptable in a truly disposable scratch environment used to read behavior.

Namespace and provider-class drift. Small, low-traffic packages frequently have a composer.json autoload namespace that doesn't match the directory layout or the class name in the README. After install, run composer dump-autoload -o and confirm the provider class resolves:

php artisan tinker
>>> class_exists('Toro\WidgetInstaller\WidgetInstallerServiceProvider');

A false here explains 90% of "the command doesn't exist" errors.

Classic Laravel package pitfalls that apply doubly to unmaintained ones:

• vendor:publish without a --tag publishes everything, including assets you don't want. Run php artisan vendor:publish interactively first to enumerate tags.
• Publishing overwrites — there's usually no merge. Publish to a clean tree and diff before committing.
• Hardcoded base_path() / app_path() calls break under symlinked deploys (Envoyer, Deployer) and when the app is a package inside a monorepo.

Permissions. Installers write to disk. Under Docker or a deploy user, storage/ and the target directory need to be writable by the PHP process, not just by your shell user. This is the single most common "works on my machine" failure for scaffold commands.

Debugging checklist, in order:

1. php artisan list | grep -i <command> — does the command exist at all?
2. php artisan vendor:publish (interactive) — did config/assets actually land?
3. Re-run the command with -vvv.
4. tail storage/logs/laravel.log; check for swallowed exceptions in the command's handle().
5. Read the command's handle() directly — in a package this size it is short enough that reading the implementation is faster than any amount of black-box debugging.

Extension points, such as they are: the published config, any published stubs/views, and container bindings registered by the provider. Because there is no maintenance, any real customization should go through forking into a local path repository rather than fighting the package's config surface. That also gives you the ability to add PHP 8 types and modern Laravel support if the scaffolding logic is genuinely worth keeping.

Bottom line for day-to-day leverage: near zero as a live dependency. The realistic value is a 10–30 minute read of src/ to harvest its widget-scaffolding approach, followed by writing a small php artisan make:widget command of your own — roughly 50 lines, fully typed, tested, and under your control.