Migration Bundle Laravel Package

Product Decisions This Supports

• Template engine strategy — this package is the enabler/blocker for using Twig inside a Laravel codebase. It supports the decision to standardize on Twig (familiar to Symfony/Twig-literate engineers and to design/front-end contributors) versus staying Blade-only.
• Major-version upgrade sequencing — v2.1.2 ("Fix twig 3.0 support") directly affects the Twig 2 → Twig 3 migration decision. It moves that work from "blocked on our bridge" to "plannable."
• Security and maintenance posture — Twig 2 is end-of-life and no longer receives security fixes. A patch that makes Twig 3 work cleanly is risk reduction, not a feature.
• Build vs buy — maintaining an in-house Twig↔Laravel bridge (service provider, view finder, extension registration, Blade coexistence) versus adopting this package. The release pattern here — small, targeted patches — reads as maintained-but-lean.
• Roadmap inputs — any "shared template layer," agency/handoff, cross-framework template reuse, or design-system work that assumes Twig is now marginally safer to scope.
• What it does not support — there are no new features here. This patch should not be used to justify new product capability.

When to Consider This Package

Adopt or keep when:

• You have existing Twig templates or Twig-fluent contributors and want them running inside Laravel's view and extension ecosystem.
• You're planning a Twig major-version upgrade and need the bridge to keep pace — this release is evidence it does, at least for 3.0.
• You want incremental adoption: Twig alongside Blade rather than a rewrite.
• You need to keep a template layer shared with a Symfony service alive in a Laravel app.

Look elsewhere or defer when:

• You're Blade-only in a single-team codebase — the bridge is pure overhead.
• You need vendor-backed SLAs; this is community maintenance with small patch releases.
• You depend on Blade-specific features (components, slots, @once) that Twig does not mirror.
• Your Twig extensions are load-bearing and unverified against Twig 3. A "support fix" landing in a patch release warrants your own compatibility test rather than trust in the changelog.

Due diligence specific to this release: confirm the Composer constraint actually permits twig/twig ^3, and run your template suite against Twig 3 before merging. A one-line changelog entry is not a compatibility guarantee.

How to Pitch It (Stakeholders)

Executives: A small, targeted maintenance release restores Twig 3 support in our Laravel templating integration. No new features and no breaking changes implied — low risk. Its value is that it unblocks an upgrade to a supported Twig major version, which matters because Twig 2 is end-of-life and will not receive security patches. Frame it as "keeps a dependency current and removes a future forced-migration risk," not as new capability.

Engineering: v2.1.2 fixes Twig 3.0 support in the Twig↔Laravel bridge. Treat it as a patch: pin it, run the template and extension test suite, verify the twig/twig constraint allows ^3, then upgrade Twig in a separate, reviewable PR. Watch for Twig extension API changes between 2.x and 3.x, and confirm view-finder and namespace behavior is unchanged in your setup.

Product: No user-facing impact. If the roadmap contains items that assume Twig-based templates — shared design system, cross-framework template reuse, agency handoff — this release makes them slightly safer to scope, but it is dependency hygiene, not evidence of active feature investment in the package. It should not be the sole justification for a Twig-first architecture decision; that call should rest on team fluency and genuine template-reuse needs, with this package as one input among several.