Css Inliner Bundle Laravel Package

Product Decisions This Supports

• Framework mismatch, resolve first: despite the brief, this is a Symfony bundle, not a Laravel package. It ships a Twig tag ({% cssinline %}) and a bundle class registered in AppKernel. There is no Laravel service provider, no Blade directive, no config publishing. Any Laravel decision here is really a decision about the underlying library (tijsverkoyen/CssToInlineStyles), not this repo.
• Email rendering fidelity (the actual capability): transactional and notification email clients (Gmail, Outlook) strip or ignore <style> blocks. Inlining CSS onto elements is table stakes for consistent email rendering. This bundle is a thin convenience layer for that step inside Twig templates.
• Build vs. buy → "neither, vendor the pattern": the value is ~30 lines of Twig extension wrapping a mature third-party library. The buy decision should be made on CssToInlineStyles (independent maintenance, real usage), not on this wrapper (6 stars, 0 dependents, last release March 2020).
• Roadmap signal: if styled email is on the roadmap (receipts, digests, lifecycle/marketing mail), budget for an inlining step in the rendering pipeline. Whether it comes from this package, the underlying library directly, or the mailer's own support is an implementation detail — that it exists is the product decision.
• Scope boundary this sets: "Nothing more, nothing less" is accurate and worth internalising. It does not handle media queries, @font-face, pseudo-selectors, or client-specific hacks — those still require a <style> block for clients that honour it, plus a fallback strategy. Do not let stakeholders read "CSS inliner" as "email design system."

When to Consider This Package

Consider it when:

• You are on Symfony 4/5 + Twig and want a one-tag inlining step with near-zero integration cost.
• Email styling is simple — single-column, inline-able properties, no responsive breakpoints.
• Your team is comfortable treating it as source to copy rather than a dependency to track (MIT licence permits this).
• You want to prototype email rendering quickly before committing to a longer-term mail architecture.

Look elsewhere when:

• You are on Laravel. No Twig, no bundle registration path. Use CssToInlineStyles directly in a Mailable/Blade post-processing step, or a Laravel-native alternative.
• You need maintained dependencies. Last release 2020-03-20, single maintainer, no recent activity. If your supply-chain policy requires active maintenance or CVE responsiveness, this fails the gate.
• You need responsive email. Inlining fundamentally breaks media queries; plan a hybrid (inlined base + retained <style> block) or use a purpose-built email framework.
• Adoption risk matters. 6 stars and 0 dependents means essentially no peer validation — no community to catch breakage when Symfony or PHP versions move.
• You need anything beyond <style> → style="". No asset handling, no CSS preprocessor, no per-client targeting.

How to Pitch It (Stakeholders)

To executives (one paragraph): Styled transactional email is a customer-facing capability, and the technical blocker is that major inbox providers strip stylesheets. This package is a small, unmaintained Symfony-only helper that solves that one step — it is not a platform investment and not a strategic dependency. Recommendation: capture the capability on the roadmap, but do not adopt this repo as a dependency. Adopt the underlying inlining library directly (or vendor the ~30-line Twig tag under MIT), which removes the maintenance risk while keeping the delivery date.

To engineering (the ask): This is a convenience wrapper around CssToInlineStyles with one Twig tag and a bundle registration. It is straightforward, readable, and MIT-licensed — but it is a 2020 artifact scoped to Symfony 4/5. Two viable paths: (a) if we are on Symfony, vendor or fork the tag so we own the two files; (b) if we are on Laravel, skip the repo entirely and call the underlying library from our mail pipeline. Either way, confirm current PHP/Symfony compatibility and add an email-rendering regression test in Litmus or Email on Acid before we ship anything customer-facing.

Bottom line: the capability is worth having; this repository is not worth depending on.