Blade Laravel Package

Product Decisions This Supports

• Build vs. buy on the templating layer. The core decision this package enables is whether to spend engineering weeks hand-rolling a view layer for a non-Laravel surface (WordPress theme, legacy PHP app, CLI/static generator, microservice, single-file script) or to adopt a thin wrapper over a syntax the team already knows. For a team with Laravel fluency, this converts a "write a template engine" epic into a "composer require and wire up a bootstrap" ticket — a scope reduction measurable in sprints, not days.
• Platform expansion into WordPress-adjacent surfaces. The primary product use case is delivering features onto a CMS-hosted property without standing up a full Laravel application. If the roadmap includes a marketing site, a municipal/portal front end, or a WordPress theme that needs real layout inheritance, this package is the shortest credible path — @extends, @section, @component, and @include behave as they do in Laravel, so existing Blade templates port over rather than being rewritten.
• Feature scope: reuse of existing template assets. Because templates are portable, any product work already expressed as Blade views becomes an asset with a second home. That widens what a small team can ship without a second front-end stack, and it lowers the cost of a future migration in either direction (WordPress → Laravel or the reverse), which is a real option-value argument for roadmap sequencing.
• Roadmap de-risking through a single rendering seam. A thin internal adapter class around the render call means the templating engine is a swappable implementation detail, not an architectural commitment. That lets a PM approve a pilot without foreclosing later choices — the decision is reversible, which changes it from a platform bet into a scoped experiment.
• Delivery velocity on the non-Laravel side of the estate. Custom directives map framework-only helpers (asset(), route(), csrf_field()) to whatever the host environment actually provides. Product-wise this is what makes "add a page to the WordPress site" a small story rather than a negotiation about framework bootstrapping.
• What it explicitly does not support. It is not a reason to introduce Blade into a Laravel service — that would add dependency surface around capability the framework already owns. It does not supply @auth, @can, @csrf, @vite, route(), or old(), so any roadmap item that depends on authenticated user context, authorization gates, or Laravel's asset pipeline should be scoped as separate work, not assumed to come along.

When to Consider This Package

• Adopt when the target surface is genuinely non-Laravel — WordPress theme/plugin, legacy PHP, CLI or static generation — and the team already writes Blade. That combination is where the payoff is real and immediate.
• Adopt when the scope is a single low-traffic site or a bounded feature, and there is a named engineer who can own the compiled-view cache and deployment story. Keep it at pilot scale first; standardising across the estate on a five-star, single-team package is not a proportionate risk.
• Consider only after verification when the project already pins other illuminate/* components. The wrapper constrains an Illuminate release line, and that constraint determines whether the product can take upstream Laravel security patches on its own schedule or on the maintainer's. This is the single gating technical question and it should be answered before any roadmap commitment is made.
• Look elsewhere when the destination is a Laravel application — use framework-native Blade. Also look elsewhere if the product needs vendor SLA, a security intake process, or a support contract: this is public-sector open source from Helsingborg municipality with no commercial backstop, so internal ownership of fixes is the operating assumption.
• Look elsewhere when the requirement is a rich, opinionated CMS templating layer — Twig/Timber is the established WordPress-adjacent choice, and running two engines that both claim template resolution order is a maintenance trap, not a feature.
• Look elsewhere when the roadmap depends on Laravel helpers, authorization, or asset bundling inside the templates. Those are absent by design, and every one of them becomes custom directive work you own. Also weigh the long-term picture: 3.x versioning implies prior API churn, the changelog for 3.5.1 is a bare compare link, and upstream abandonment would leave you on an unpatched compiler with a migration as the only exit. Reasonable for a pilot; harder to defend as a load-bearing platform.
• Pre-adoption checklist for the PM to demand: target runtime confirmed, illuminate/* constraints read, 3.5.0→3.5.1 diff reviewed, licence cleared by legal, PHP version matrix checked, and a CI smoke test that renders one page committed alongside the first integration.

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a small, MIT-licensed utility that lets us reuse Laravel's template syntax on parts of our estate that aren't Laravel — principally the WordPress-hosted surface. It turns a "build a templating layer" effort into a short integration, lets existing templates move between platforms instead of being rewritten, and is deliberately reversible: a thin adapter we own means we can pilot it, measure it, and remove it without a repo-wide rewrite. The honest caveats are that it's maintained by a single public-sector team with no support contract, it constrains which versions of the underlying Laravel view component we can use, and we'd own fixing problems ourselves. That makes it appropriate for a scoped pilot on one low-traffic property, not for standardising across the estate. Cost is roughly half a day for a Laravel-fluent engineer to be productive and two to three days to train the person who owns the WordPress integration and the cache/deploy story; the ongoing ask is one named owner watching releases and a small allowance for contributing fixes upstream.

For engineering — the substance. Standalone Blade outside the framework: render, share, directive, if, view composers. Compile-once, serve-many, so per-request cost is negligible and scaling is a cache-coordination problem, not a CPU one. Three things to absorb before we ship: there's no container and no config(), so everything is passed explicitly; the compiled-view cache directory must exist and be writable or we get opaque "unable to write compiled view" failures; and there's no auto-reload in dev, so a stale render means clearing the cache by hand. Pin to 3.5.1 exactly rather than a caret range so patches arrive as deliberate pull requests. Wrap the render call in one adapter class we own, snapshot-test the rendered string output in CI, and treat {!! !!} as something requiring review. Adopt on the non-Laravel side only — inside a Laravel service this package is a net negative on dependency surface.