Laravel Pug Laravel Package

Product Decisions This Supports

• Template layer choice for Laravel apps: laravel-pug lets teams author views in Pug/Jade syntax and render them through Laravel's view system, so it directly informs the "Blade vs. Pug" decision for any product with a heavy server-rendered UI (marketing sites, admin panels, CMS-driven pages, email/HTML fragments).
• Build vs. buy: this is a thin, single-purpose adapter over the Phug engine. It is only worth building in-house if you need custom compilation pipelines or non-standard Laravel view integration — otherwise this package is the cheapest credible option and keeps the maintenance burden on the upstream Phug community.
• Roadmap / upgrade planning: release 2.5.0 widens the dependency constraint to permit Phug 2, which is primarily a compatibility release rather than a feature release. It unlocks the path to keeping the templating layer current with newer PHP/Laravel runtimes, and it removes a hard ceiling that would otherwise force a fork or a migration when Phug 1 stops receiving fixes.
• Risk management decisions: the practical value here is avoiding forced migrations. A pinned old templating engine is a slow-moving liability (PHP version blocks, security patches, abandoned upstream). This release lets you defer a full Pug-to-Blade rewrite by one or more planning cycles.
• Use cases it supports well: content-heavy marketing pages, multi-tenant sites where designers hand off Pug markup, and teams with existing Node/Pug design assets who want parity between front-end prototypes and server-rendered output.
• What it does not decide: it is not a front-end framework decision, not a component/SPA strategy, and not a replacement for Blade's ecosystem (Livewire, Blade components, community packages that assume .blade.php).

When to Consider This Package

Adopt when:

• You already have Pug templates, design-system assets, or a design team fluent in Pug/Jade, and rewriting them into Blade has real cost.
• You are on a supported Laravel version and a maintained PHP runtime, and can run Phug 2 (verify your PHP version against Phug 2's requirements before committing — the constraint change does not guarantee runtime compatibility on older PHP).
• Your views are predominantly server-rendered and static-ish; you are not leaning heavily on Blade components, Livewire, or Inertia.
• You want indentation-based, terse markup with mixins/includes and are willing to accept a smaller ecosystem than Blade's.

Look elsewhere when:

• Your team is Blade-native or your codebase is entangled with Blade components, slots, and Livewire — the interop tax outweighs the syntax gains.
• You need long-term vendor stability with a large contributor base; this is a small, single-maintainer package wrapping another small package (Phug). Two layers of upstream risk.
• Your build depends on strict dependency pinning or audited supply chains; a major-version dependency bump like Phug 2 needs its own review cycle.
• Rendering performance or IDE/tooling support (Blade has far better editor and static-analysis coverage) is a priority.
• You are standardizing on Vue/React/Inertia for the UI — the server templating layer becomes marginal.

Specific to 2.5.0: treat this as a green light to plan an upgrade, not a green light to ship. The release only relaxes a Composer constraint; behavioral differences between Phug 1 and Phug 2 (parsing edge cases, attribute handling, error messages) live upstream and are not covered by this changelog. Require a regression pass over your most complex templates before adopting.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our server-side templating layer sits on a small open-source adapter, bkwld/laravel-pug, which lets us write views in the concise Pug syntax instead of Laravel's default Blade. The new 2.5.0 release is a maintenance release: it removes a version ceiling so the package can run on the current generation of its underlying engine (Phug 2). The business value is continuity — it keeps a dependency we already rely on upgradeable and reduces the chance of an unplanned rewrite. There is no new user-facing capability and no new cost; the main decision it enables is when, not whether, to modernize our PHP runtime.

For engineering (the ask):

• 2.5.0 changes only the Phug version constraint — no breaking API changes are announced in this release, but Phug 2 itself is a major version. Do not assume drop-in parity.
• Action: bump the dependency in a branch, run the full view-rendering test suite plus a manual pass over the highest-complexity templates (deep mixins, conditionals, attribute interpolation, raw HTML blocks). Watch compile-time errors and whitespace/attribute output diffs.
• Action: confirm our PHP version satisfies Phug 2's requirements before the bump, and confirm Phug 2 is not itself a dead end (check its release cadence and PHP support matrix).
• Guardrail: keep a rollback path to the 2.4.x / Phug 1 combination for one release cycle. If our template suite has thin coverage, treat this as a spike rather than a scheduled upgrade.
• Strategic note: the fact that this package needed a release purely to track Phug's major version is a reminder of its two-layer upstream dependency. If our Pug surface area is small, a gradual Blade migration remains the lower-risk long-term position; if it is large, budget for tracking Phug releases deliberately rather than reactively.