Twig Collector Extension Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (or build vs. adopt). This package is a candidate to replace code we would otherwise write and maintain in-house. The decision it informs is whether the functionality is commodity plumbing (good candidate for adoption) or a differentiator we should own. For most Laravel applications, framework-adjacent concerns — auth scaffolding, admin/CRUD layers, API conventions, integrations with first-party Laravel services — are commodity and belong in a dependency, not in our backlog.
• Roadmap sequencing. Release 1.1.2 is a patch-level release, which signals active maintenance and bug-fix hygiene rather than new capability. That is the ideal signal for scheduling adoption: it means the package is being tended to, and there is no migration work attached to the upgrade. Adoption can be slotted into an existing sprint rather than requiring its own epic.
• Dependency and versioning policy. Adopting this package means committing to a Composer constraint in composer.json. The PM decision is which constraint to pin (^1.1) and what our tolerance is for tracking minor releases. A 1.1.x line implies SemVer discipline and an expectation that minor bumps are additive, not breaking — worth confirming in the changelog before we rely on it.
• Feature scoping and time-to-market. Each capability the package covers is capability we do not have to design, spec, build, review, and maintain. The product decision is whether the saved engineering weeks outrank the loss of control over that surface area.
• Risk register entry. Every third-party dependency is a standing liability: abandonment, unpatched security issues, license changes, or a major-version rewrite that forces our hand. Adopting it now is also a decision about how we would exit later.
• Use cases to validate against. Best fit is typically internal tooling, back-office/admin surfaces, and integration glue where the requirements are conventional. Poor fit is anything customer-facing, performance-critical, or tied to our differentiation.

When to Consider This Package

Adopt when:

• The problem it solves is not a core differentiator — we would be writing boilerplate we have written before.
• Our Laravel and PHP versions fall within the package's supported matrix, and the maintainers state that matrix explicitly.
• The package has a visible release cadence (this 1.1.2 patch is the evidence), a changelog we can read, and a track record on security disclosures.
• Licensing is compatible with our distribution model (MIT/Apache are the easy cases; verify before shipping anything closed-source).
• Integration is idiomatic Laravel — service provider, config publish, facade/contracts — so it does not fight the framework or our conventions.
• The blast radius is contained: we can wrap it behind our own interface or keep it confined to one layer of the app.

Look elsewhere when:

• The functionality sits in our differentiated core. Owning it is the point.
• We would need to fork or patch it substantially to fit our domain — at that point we have taken on the dependency and the maintenance.
• It is abandoned: no release in a long stretch, unaddressed issues, or no stated support policy for the Laravel majors we run.
• It reaches deeply into framework internals or overrides conventions in ways that will complicate future Laravel upgrades.
• Requirements are unusual enough that the package's abstractions become a constraint we spend sprints working around.
• It duplicates capability already available from Laravel first-party or from a dependency we already carry — consolidation beats a second library.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small, actively maintained Laravel package as a replacement for code we would otherwise build ourselves. The current release, 1.1.2, is a patch-level update — bug fixes and maintenance, no breaking changes and no migration cost. That makes this a low-risk moment to test adoption. The upside is engineering time returned to the roadmap; the cost is a new third-party dependency and the ongoing obligation to track its releases. Recommendation: a timeboxed spike against one real surface, with a go/no-go before we commit broadly.

For engineering: Adopt behind an explicit Composer constraint (^1.1), verify compatibility with our supported Laravel/PHP versions, and confirm the changelog reflects SemVer discipline. Integrate in one bounded area first — service provider registration, published config, no framework-internal hooks. Add it to the dependency review list so we catch future security advisories and Laravel major-version support. Document the exit path: if the package stalls, how much code is ours to absorb?

The ask: a short spike, a written go/no-go, and a named owner for tracking upstream releases. Not a broad rollout before those three things exist.