Merge Token Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for templated content. The package addresses the “merge tokens into templates” problem space: personalized emails, notifications, invoices/statements, contract generation, white-label copy, and mail merge. If this capability is on the roadmap, it helps frame the problem — but should not be mistaken for a production-ready solution.
• Build vs. buy vs. borrow. With zero stars, zero dependents, no visible release cadence, and no community maintenance, the defensible product decision is build or borrow the pattern, do not adopt the dependency. Token replacement is a small, well-understood capability; taking on an unmaintained dependency is a net-negative trade.
• Architecture-fit check. Despite being presented as a Laravel/PHP package, this is a Symfony bundle. In a Laravel codebase, that means pulling Symfony bundle conventions, service-container wiring, and likely additional Symfony components into an app that expects service providers and facades. That mismatch is a material adoption cost.
• Use-case triage. It helps separate commodity templating from differentiated workflow features. Personalization tokens are commodity; conditional logic, approvals, e-signature, and document versioning are differentiating and should not be outsourced to a package like this.
• Risk-register input. Token merging is an injection and data-leak surface: user-controlled templates, unescaped token values, and PII flowing into rendered documents all require an explicit threat model. Evaluating this package surfaces the security questions that must be answered regardless of implementation choice.
• Competitive/alternative benchmark. Twig (with sandbox), Blade components, or a small in-house resolver with an explicit token allowlist and typed formatters are the realistic benchmarks. This package is useful mainly as prior art.

When to Consider This Package

Consider it only in narrow circumstances:

• You are on Symfony — not Laravel — need minimal token substitution, and are prepared to vendor or fork the code, pinning a commit and owning maintenance, tests, and security review.
• You want a reference implementation to read before writing your own resolver. The parsing and resolution approach may be a useful sketch for an internal design document.
• You need a short-lived internal tool where the dependency will never ship to production customers and no support relationship is required.

Look elsewhere — or build in-house — when any of the following hold:

• You are on Laravel. Prefer Blade, a maintained standalone template engine, or a first-party resolver rather than bridging a Symfony bundle.
• You need a maintained dependency. No stars, no dependents, and no visible activity means no community bug-fixing, no security advisories, and no guarantee of PHP/Symfony version support. Assume you become the maintainer on day one.
• Templates or token values are user-supplied. You need escaping guarantees, sandboxing, and a documented threat model; there is no evidence of one here.
• You need more than flat substitution. Conditionals, loops, formatting (dates, currency, locale), HTML-vs-plaintext escaping, missing-token fallbacks, and PDF rendering are table stakes in mature engines and typically absent from small bundles.
• You need auditability or compliance. Document generation often touches regulated output; you need a codebase you can fully review and a verified license.
• You need support, SLAs, or a vendor relationship. No commercial backing is implied.
• Compatibility is unproven. Symfony bundles of this vintage often pin older Symfony/PHP versions; modern Laravel requires PHP 8.1+ and Symfony 6/7 components. Validate with composer require --dry-run before any commitment.

How to Pitch It (Stakeholders)

Executive summary: We evaluated idci/merge-token-bundle for templated document and message generation. It is a small Symfony bundle with no adoption signals — zero stars, zero dependents, no visible maintenance — and it does not fit our Laravel stack without custom integration work. Recommendation: do not adopt as a dependency. Treat it as a design reference and implement token merging in-house, or on a maintained engine such as Twig or Blade, in roughly a few engineering days.

To engineering: The problem is well understood and low-complexity; the risk is in the dependency, not the feature. A first-party resolver of roughly 200–400 lines gives us escaping control, a token allowlist, typed formatters, strict handling of unknown tokens, and test coverage — none of which we can assume from an unmaintained third-party bundle. If we want prior art, we read this repository once and move on.

To leadership: This is a cost-avoidance and risk-avoidance recommendation, not a capability gap. We can deliver the feature on schedule without inheriting an orphaned dependency, and we avoid the downstream cost of becoming its de facto maintainer. The only trade-off is a small amount of up-front implementation time in exchange for full control over a PII-adjacent code path.

Decision requested: Approve in-house implementation, or a vetted maintained alternative, for the templating capability; close this package as “evaluated, not adopted.”