View Laravel Package

Getting Started

clean/view is a lightweight view-rendering component from the clean PHP organisation. It is a standalone template layer — do not assume Laravel's view() helper, Blade directives, or the View facade exist after installing it. Treat it as a small renderer you wire into your own code.

Minimal steps

1. Install with Composer and inspect what actually landed on disk; the package is unmaintained and under-starred, so read the source before trusting the README:

   composer require clean/view
   ls -R vendor/clean/view
   cat vendor/clean/view/README.md
   cat vendor/clean/view/composer.json
   

2. Read composer.json first. Check the require block (PHP version, PSR interfaces), the autoload PSR-4 namespace, and whether it declares a Laravel extra.laravel.providers entry. If there's no provider, there is no auto-discovery and no Laravel integration — you construct the renderer yourself.
3. Find the public API by listing the classes:

   grep -rn "public function" vendor/clean/view/src | head -50
   

   Look for a renderer/factory class and a render(string $template, array $data) style entry point, plus whatever interface represents the template path configuration.
4. First use case — render a single template outside Laravel's view stack. This is the package's only realistic day-to-day value: a tiny, framework-agnostic renderer for a microservice, a CLI tool, a queued worker, or a mailer that doesn't boot a full Laravel container:

   $view = new \Clean\View\View(__DIR__ . '/templates');
   echo $view->render('welcome', ['name' => 'Ada']);
   

   (Adjust the class/path-argument names to whatever the source actually exposes — verify before writing.)

Do not start by trying to register it as a replacement for Blade in an existing Laravel app. Start by rendering one template in isolation, then decide whether the ergonomics justify the integration cost.

Implementation Patterns

Standalone renderer in a non-Laravel context. The cleanest fit. Wire the renderer once in your bootstrap and pass it through your container:

// bootstrap.php
$container->set(ViewInterface::class, fn () => new View(
    templatePath: __DIR__ . '/../resources/views',
    cachePath:    __DIR__ . '/../storage/views', // if supported
));

In a Laravel app, bind it in a service provider with an explicit singleton and a config key, rather than relying on auto-discovery:

// App\Providers\CleanViewServiceProvider
public function register(): void
{
    $this->app->singleton(ViewInterface::class, fn ($app) => new View(
        $app['config']->get('view.clean.path', resource_path('clean-views')),
    ));
}

Keep it out of the HTTP view layer. Laravel's view() / View::make() / @extends machinery is deeply coupled to Illuminate\View\*. If you want clean/view in a Laravel app, use it for a narrow, non-HTTP surface — rendered email bodies, PDFs, CLI output, generated Markdown — and leave web responses to Blade. Mixing two template engines in the same response pipeline is where bugs breed.

Explicit data contracts. With no @props/@aware equivalents, every template's input is a plain array. Collapse that into small value objects or DTOs and pass arrays at the boundary; that's how you keep templates from drifting into "whatever keys the controller happened to set."

Layouts via composition, not inheritance. If the package offers partials/includes, build a layout template that renders a content variable pre-rendered by the caller. If it only supports flat rendering, do the nesting yourself:

$body = $view->render('emails/receipt-body', $data);
$html = $view->render('emails/layout', ['content' => $body] + $data);

Escaping you control. Assume the renderer escapes nothing unless the source proves otherwise. Wrap every interpolation originating from user input in htmlspecialchars($v, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') before handing it to the renderer, or pass pre-escaped values and keep raw ones under an obvious _raw suffix.

Testing. Snapshot the rendered output rather than asserting on template internals; that keeps your tests valid if you later swap the renderer out:

$this->assertSame(file_get_contents(__DIR__.'/fixtures/receipt.html'), $view->render('receipt', $data));

Gotchas and Tips

• Zero stars, zero dependents, zero score. There is no community to consult and no upstream fixes coming. Read every line of src/ before adding it to a dependency graph that matters; treat it as vendored third-party code you are now responsible for. If the surface area is a few hundred lines, consider forking it into app/Support and dropping the Composer dependency entirely.
• No framework glue is guaranteed. Auto-discovery, facades, config publishing, and Artisan commands are all Laravel-specific niceties the package may not implement. Verify extra.laravel in composer.json before assuming php artisan vendor:publish works. If absent, register everything by hand.
• PHP version and PSR constraints. Check the require block against your runtime. A low-activity package often pins stale PSR versions (psr/container ^1.0 alongside a Laravel version expecting ^2.0), producing Composer conflicts that look like your app's fault. Resolve with an alias or --with-all-dependencies only after confirming the code is actually compatible.
• Silent null returns. Small renderers frequently return an empty string or null when a template file is missing rather than throwing. Add your own existence check before rendering, or you will ship blank emails. Wrap the render call in a guard that asserts non-empty output in non-production.
• No compiled-template cache, or a cache with no invalidation. If the package compiles templates, find where it writes and confirm a stale-cache story exists. In Docker, an un-writable cache directory manifests as a confusing render failure — point the cache at a path inside the container's writable layer, not a bind mount the process user can't touch.
• Path traversal. A renderer that concatenates $templatePath . '/' . $name . '.php' will happily load ../../etc/passwd if $name is ever user-influenced. Never pass request input as the template name; map it through an allow-list of known views.
• Debugging. There's no error-handler integration. When a template fails half-rendered, catch the exception and diff the data array you passed against the keys the template expects (grep -o '\$[a-z_]*' template.php | sort -u). Missing-key warnings buried in output buffering are the usual culprit.
• Extension points. Look for a compiler/engine interface you can decorate rather than editing vendor code — that keeps a future fork or replacement a one-line change. If none exists, wrap the package behind your own ViewRenderer interface on day one so the rest of your app never imports Clean\View\* directly.
• Replacement path. For a Laravel developer the realistic alternatives are Blade (with Illuminate\View pulled into a non-Laravel app via illuminate/view), Twig, or Latte — all maintained, all documented, all with caching. Adopt clean/view only for its size or a specific constraint; otherwise the maintenance cost outweighs the footprint saving.