Pug Filter Stylus Laravel Package

Product Decisions This Supports

• View-layer standardisation: Choosing whether to standardise on Pug (via pug-php) or stay on Blade for new Laravel surfaces. This package is the integration seam, so the decision is really "Pug vs. Blade" with an adoption cost attached — not a standalone library pick.
• Build vs. buy for templating: A thin wrapper over an existing engine means you buy the engine and maintain only the adapter. That is usually the right call versus building a Pug compiler in-house, but it ties your roadmap to a third-party engine's release cadence.
• Upgrade sequencing (the 2.1.0 driver): Pug-php 3 compatibility directly unblocks PHP/Laravel runtime upgrades and security patching for teams already on Pug. Treat this release as an enabler on the platform-upgrade roadmap, not a feature release — it removes a blocker rather than adding capability.
• Migration and consolidation scoping: If you are consolidating front-end templates (e.g. migrating a legacy Node/Pug asset pipeline into Laravel), this package determines how much of that work can stay in PHP versus requiring a JS build step.
• Hiring and onboarding cost modelling: Pug is a non-default skill in the PHP market. Adoption is a lasting tax on onboarding and code review, and should be priced into the decision accordingly.

When to Consider This Package

Adopt when:

• You have a substantial existing Pug template corpus (typically inherited from a Node/Express service or a design-system port) and rewriting it to Blade is more expensive than carrying an adapter.
• Your team already knows Pug and values its indentation-based syntax and mixin model enough to accept a smaller ecosystem.
• You are on pug-php 3 and are currently pinned to an older adapter — 2.1.0 is the release that lets you stay current and keep receiving upstream fixes.
• You want an incremental migration path: render Pug alongside Blade rather than doing a big-bang rewrite.

Look elsewhere when:

• You are starting greenfield. Blade is the default, is first-party, has the deepest tooling and community support, and carries no compatibility risk. Reach for Pug only with a concrete reason.
• You need Livewire, Inertia, or component-driven reactivity — Blade (or a JS framework) is the better fit and this package adds friction.
• You are on a strict dependency-vetting regime: this is a small-maintainer adapter whose releases are driven by an upstream engine's cadence. Confirm maintenance signals and a fallback plan before committing.
• Performance at scale is a hard constraint — templating engines in PHP userland add compile/render overhead versus Blade's compiled approach. Benchmark against your actual template complexity rather than assuming.

How to Pitch It (Stakeholders)

To executives: This is a maintenance-and-compatibility update, not a product feature. Release 2.1.0 adds support for pug-php 3, which unblocks our PHP/Laravel upgrade path for any product area currently rendering Pug templates. It costs us nothing to adopt and removes a known upgrade blocker. The strategic question it feeds is whether we continue supporting Pug as a second templating language at all — that decision carries ongoing onboarding and maintenance cost and should be made deliberately rather than by inertia.

To engineering: 2.1.0 is a compatibility bump — it brings the Laravel adapter in line with pug-php 3. Low-risk to adopt if you are already on the package; verify your pug-php constraint and run the view-rendering test suite, since major-version engine upgrades can shift compilation behaviour and option names. If you are not already on Pug, the honest recommendation is Blade. If you are on Pug, upgrade to stay patched, and treat this as the moment to record why we are on Pug and what it would take to leave — so the choice stays reversible.