Biolife Style Provider Extension Laravel Package

Getting Started

This is a PyroCMS / Streams Platform addon (visiosoft/* vendor, *-extension suffix), not a generic Laravel package. Treat it as a theme-support addon that registers style/asset providers for the Biolife theme. Before you invest time, sanity-check it: 0 stars, 0 dependents, a single release in mid‑2023 and a placeholder description mean there is almost no public signal. Confirm the code does what you need by reading it, not by reading docs — there likely aren't any.

Minimal steps:

composer require visiosoft/biolife_style_provider-extension
php artisan addon:install visiosoft.extension.biolife_style_provider_extension

If the addon:install slug is rejected, derive the real slug from the composer.json extra block or the type field (streams-addon / pyrocms-theme), or just list what got registered:

php artisan addon:list
php artisan addon:list --installed

Where to look first, in this order:

1. composer.json — type, extra.slug, require (does it pin pyrocms/pyrocms or anomaly/streams-platform versions?), and whether it declares theme/addon dependencies.
2. src/*ServiceProvider.php — the register()/boot() methods are the entire contract. Look for Asset::add(...), View::addNamespace(...), Config::merge(...), route registration, and any bindings.
3. resources/ — assets/, views/, config/, lang/. This tells you whether it ships CSS directly or only wires up paths.
4. migrations/ — if present, installing the addon will run them; check before touching production.

First real use case: you have the Biolife theme installed and its styles aren't compiling or aren't loading in the right order. This addon is meant to be the thing that supplies/registers those style providers, so the first win is confirming that installing it changes the <link>/bundled output at all. Compile and inspect:

php artisan assets:clear
php artisan streams:compile
# then view-source the front end and diff the stylesheet list before/after

Implementation Patterns

Declare it as an upstream dependency, don't call it directly. If the Biolife theme is the consumer, the idiomatic pattern is to let the theme (or your own thin "site" addon) require this package and depend on its addon slug. Your application code should never invoke its classes by name — that keeps the blast radius small if you later pin, fork, or drop it.

Style-provider registration is the integration point. Expect the service provider to register named assets/paths, roughly:

// illustrative — verify against src/
public function boot(Asset $asset)
{
    $asset->add('biolife.css', 'visiosoft.extension.biolife_style_provider::css/biolife.css');
}

Consume it via the Streams asset facade / asset() in your layout rather than hardcoding vendor paths:

{{ asset_add('styles.css', 'visiosoft.extension.biolife_style_provider::css/biolife.css') }}

If it exposes a view namespace, override views from your own addon rather than editing vendor/:

resources/views/visiosoft/extension/biolife_style_provider/...

Fork-and-vendor if you need changes. With one release and no dependents, upstream fixes are unlikely. Use a Composer VCS/path repository so patches live in your repo:

"repositories": [{ "type": "path", "url": "packages/biolife-style-provider" }],
"require": { "visiosoft/biolife_style_provider-extension": "*" }

Commit the patch, document the divergence, and keep the diff against the tagged release in the README so a future upstream bump is mergeable.

Treat it as a build-time dependency, not a runtime one. Realistically its only job is to influence what CSS gets compiled/bundled. That means it belongs in require (not require-dev) only if the theme hard-depends on it at render time; otherwise keep it out of production installs entirely and ship the compiled asset.

Regression guard. Add a smoke test that boots the app and asserts the style provider is registered and the expected asset name resolves — the cheapest way to catch a silent break after a Streams or PyroCMS upgrade:

$this->assertTrue(app('streams.asset')->exists('biolife.css'));

Gotchas and Tips

• Maintenance risk is the headline. One release, June 2023, zero dependents. Assume it is unmaintained. Pin an exact version, and test against every PyroCMS/Streams minor you upgrade to — breaking changes in Asset/AddonCollection bindings will surface here first.
• It is not a Laravel package. Don't try php artisan vendor:publish reflexively; PyroCMS addons publish through addon:install / addon:publish. Check php artisan list for the addon namespace commands actually available on your version.
• Assets look stale after changes. The two-cache problem: Streams' asset collection and Laravel's compiled views/config. assets:clear + streams:compile + view:clear in that order resolves 90% of "my CSS isn't updating."
• Ordering is load order. Style providers are registered in addon install/require order. If Biolife's styles lose the cascade against another theme/addon, fix it by adjusting the dependency declaration, not by adding !important.
• addon:install writes to the DB. Addon state lives in the addons table and installation may run migrations and seed. Always run it in a migrated, seeded environment first, and check whether addon:uninstall is clean before you commit to the dependency.
• Namespaced asset paths fail silently. Using visiosoft.extension.…:: before the provider has registered the namespace yields an empty string in the markup, not an exception — inspect source output rather than trusting the absence of errors.
• Extension points, in order of preference: (1) config merge override from your app, (2) view override via namespace, (3) subclass the service provider and rebind in your own addon's register(), (4) fork. Never edit vendor/.
• Composer metadata is your documentation. With no external docs, composer.json + the service provider + resources/ are the spec. Read all three before writing any integration code; time spent here is cheaper than debugging a silently-absent stylesheet.