Components Laravel Package

Getting Started

soft-passio/components is a low-signal package: zero stars, zero dependents, and a single tagged release from June 2020. Treat it as an internal artifact that happened to be published rather than a maintained library. Before writing a single line against it, spend ten minutes confirming what it actually ships.

Step 1 — Inspect the archive locally, not on GitHub.

composer require soft-passio/components:^1.0
# or, safer for an unmaintained package:
composer require soft-passio/components:1.0.*

Then read the installed tree:

ls vendor/soft-passio/components
cat vendor/soft-passio/components/composer.json
find vendor/soft-passio/components -maxdepth 2 -type d

Look for three things: a src/ directory (PHP classes), a resources/views/ directory (Blade components), and a service provider registered under extra.laravel.providers in its composer.json. If there is no provider and no extra.laravel block, the package is either classmap-only or requires manual registration — both are yellow flags for a 2020 package that may target Laravel 5/6 semantics.

Step 2 — Identify the entry points. Grep for the public surface:

grep -rn "class .* extends" vendor/soft-passio/components/src | head -40
grep -rn "Blade::" vendor/soft-passio/components/src
grep -rn "componentNamespace\|anonymousComponent" vendor/soft-passio/components/src

That tells you whether you are consuming Blade component tags (<x-softpassio-...>), class-based components, or plain helper/service classes.

Step 3 — Publish and diff. If the package exposes config or views, publish them into your app so upgrades cannot silently overwrite local edits:

php artisan vendor:publish --provider="SoftPassio\Components\ComponentsServiceProvider"

First use case: render one component in an isolated Blade view (resources/views/_smoke.blade.php) against a throwaway route, confirm the markup and any required props, then delete the smoke route. Do not wire it into a real layout until you have seen its output in your own CSS/JS context — 2020-era markup assumptions (Bootstrap 4, jQuery, Tailwind 1.x) are common and will collide with a modern asset pipeline.

Where to look first: the package's own README.md, then tests/ if present, then the service provider. In a package this thin, the provider is the documentation.

Implementation Patterns

Because there is no public API reference and no ecosystem of usage examples, the day-to-day patterns below are the ones that hold for essentially any Laravel component package of this vintage. Adapt to what the source actually exposes.

Wrap, don't scatter. Do not call package components directly from fifty Blade files. Create a thin application-level namespace that delegates:

{{-- resources/views/components/ui/card.blade.php --}}
@props(['title' => null])
<x-softpassio-card {{ $attributes->merge(['class' => 'app-card']) }}>
    @if($title)<h3 class="app-card__title">{{ $title }}</h3>@endif
    {{ $slot }}
</x-softpassio-card>

This gives you one place to patch markup, one place to swap the package out, and a stable prop contract for your team. If the package is abandoned tomorrow, you rewrite one file per component instead of auditing the whole codebase.

Pin the version and commit the lockfile. composer.json should carry an exact or tilde constraint (1.0.*), not ^1.0, and composer.lock must be committed. For an unmaintained dependency this is the difference between a stable build and a surprise.

Fork-and-vendor if it becomes load-bearing. If more than a handful of components earn their keep, move the repo to a VCS path or a private Packagist entry you control:

"repositories": [
  { "type": "vcs", "url": "[email protected]:yourorg/components-fork.git" }
]

A 2020 package will not receive Laravel 11/12 compatibility patches. Vendoring lets you add a illuminate/support constraint bump and a return type or two without waiting on a maintainer who is not coming.

Treat it as a design reference, not a runtime dependency. The most defensible pattern for a 0-dependent package is to copy the components you actually want into resources/views/components/, attribute the MIT license, and drop the dependency. You keep the markup, lose the supply-chain surface, and gain the ability to edit freely.

Integration tip — service provider hygiene. If the provider registers global Blade directives or view composers, check for collisions with your own. Two packages registering the same directive name will fail at render time with a confusing "directive already exists" or silent override. php artisan about and php artisan view:cache both surface this quickly.

Gotchas and Tips

Laravel version drift is the primary risk. A June 2020 release predates Laravel 8's model factory overhaul, the Blade component attribute bag changes, and Laravel 9's minimum PHP 8 requirement. Expect deprecation notices or outright failures on Laravel 9+. Run php artisan view:cache and php artisan optimize early — these compile everything and surface broken directives and missing classes before a user hits them.

Autodiscovery may not fire. Verify the provider is actually loaded:

php artisan about | grep -i softpassio

If it is absent, either extra.laravel.providers is missing from the package's composer.json or discovery is disabled in your app. Register manually in config/app.php (Laravel 10 and below) or bootstrap/providers.php (Laravel 11+). Manual registration is usually the safer route for a stale package anyway — it makes the dependency explicit.

Namespace mismatches are common in small published packages. The package is soft-passio/components but the PHP namespace may be SoftPassio\Components, Softpassio\Components, or something unrelated to the repo name. Confirm with:

composer dump-autoload -o
grep -rn "^namespace" vendor/soft-passio/components/src

A wrong-case namespace will autoload fine on macOS and fail on Linux CI.

Asset publishing. If the package ships CSS/JS under resources/assets or public/, vendor:publish --tag=... is usually required and the tag is undocumented. List available tags by running vendor:publish with no arguments and reading the interactive menu — faster than reverse-engineering the provider.

Debugging rendering issues. When a component renders blank or throws, bypass your layout and render it in isolation with Blade::render() in php artisan tinker:

echo Blade::render('<x-softpassio-card title="x">body</x-softpassio-card>');

That isolates package behavior from your view-composer and middleware stack.

Extension points are likely minimal. For a package this size, do not expect contracts, driver managers, or events. The realistic extension points are: published config files, published views you can override in resources/views/vendor/, and subclassing public classes (check they are not final). If none of those exist, your only extension point is the fork.

Abandonment posture. Set a calendar reminder to re-audit before each major Laravel upgrade. There is no security-advisory feed for a package with no dependents, so composer audit will not protect you here. Read the diff yourself when you bump the framework, or budget the migration to a fork or in-house copy now rather than during an upgrade crunch.