Pug Filter Markdown Laravel Package

Product Decisions This Supports

• Build vs. buy on the view layer: Confirms whether the templating engine stays a third-party dependency or gets folded into custom tooling. A maintenance release that tracks upstream pug-php keeps the "buy/adopt" answer stable for another cycle.
• Upstream upgrade timing: Release 1.2.0 adds Pug-php 3 compatibility. This is the gating dependency decision for any team currently pinned to Pug-php 2 — it unblocks a coordinated major-version bump instead of a fork or a rewrite.
• Roadmap sequencing for UI work: If the team is planning a redesign, template migration, or a new marketing surface, this release is the window to standardize on Pug 3 rather than start new work on a soon-to-be-legacy compiler.
• Tech debt triage: A compatibility-only release is a low-risk, low-effort ticket. Good candidate to bundle with routine dependency maintenance rather than scheduling dedicated sprint capacity.
• Use-case validation: Supports the call on whether Pug remains the right authoring format for HTML-heavy pages (marketing, email templates, content sites) versus Blade-native views.

When to Consider This Package

Adopt when:

• The team already has Pug/Jade fluency from a Node background, or the codebase already contains Pug templates that need a migration path.
• Views are markup-heavy and low-logic — landing pages, content sites, email/HTML output — where Pug's terseness measurably reduces authoring time.
• You are on (or moving to) Pug-php 3, since 1.2.0 removes the version-compatibility blocker.
• You want a contained, swap-out-able view layer rather than a bespoke templating investment.

Look elsewhere when:

• The stack is Blade-native and leans on Blade components, slots, directives, or Livewire. Mixing engines adds cognitive overhead with little payoff.
• You need long-term vendor support, SLA, or an actively multi-maintainer project — wrapper packages around Pug-php tend to be small-team efforts.
• Existing templates were written against Pug 2 and there is no regression coverage; the major upstream bump is not free.
• Performance-sensitive rendering at scale is a hard requirement — verify compiled-template caching behavior before committing.

Migration caveat for this release: treat 1.2.0 as a dependency-major-bump release, not a feature release. Confirm PHP version floors, widened/completed pug-php constraints, and any changed option defaults; run the existing template suite against Pug 3 before rolling forward.

How to Pitch It (Stakeholders)

To executives: A small, well-scoped dependency update keeps our templating layer current and unblocks a future upgrade path we would otherwise have to pay for later as a migration project. Cost is maintenance-level; risk is contained to the view layer and reversible.

To engineering: Release 1.2.0 is compatibility work — it brings the Laravel wrapper in line with Pug-php 3. No new APIs to learn, no product-facing change. The real work item is validating our templates against the upstream major version and confirming the dependency constraints resolve cleanly. Recommend bundling with the next dependency-maintenance pass and gating on a template regression run.

Bottom line: Low-urgency, low-risk, but worth taking now — it converts a future forced migration into an opt-in one.