Embed Helpers Laravel Package

Product Decisions This Supports

• Feature scoping for media embeds: The package addresses a narrow, recurring problem — taking a pasted URL from a supported video platform (release notes show YouTube plus a youtube-short provider, and the description implies other embed platforms) and turning it into normalized video data with an embed URL (VideoDetails::getEmbedUrl()). That makes it relevant to any roadmap item like "let authors embed video in posts," "attach a video to a lesson," or "show a video in a support ticket."
• Build vs. buy on URL parsing: The real decision this informs is whether to hand-roll per-platform URL matching, ID extraction, and embed-URL construction. That logic is small but deceptively fiddly (shorts vs. watch URLs, whitespace, parameter quirks — the changelog shows the team trimming URLs and renaming "shorts" to "short"). Buying it for free (MIT) is cheap; the cost is ownership, not license.
• Data model decision: Whether to persist the source URL and derive the embed at render time, or persist generated embed HTML. This package supports the former cleanly, which is the better default for content portability and re-rendering when embed formats change. A PM should decide this explicitly rather than letting it fall out of implementation.
• Provider allowlisting as a product policy: Because the package recognizes a defined set of providers, "which platforms do we support?" becomes a visible product decision (and a moderation/security lever) rather than an open-ended input field.
• Low-stakes use cases where a thin dependency is fine: Internal CMS, marketing site, course platform, editorial tooling — places where a single-team-owned helper is proportionate and a heavyweight media platform integration would be overkill.
• Not a differentiator: This is plumbing. It should not appear on a roadmap as a feature; it should appear as a cost/risk line under one.

When to Consider This Package

Consider it when:

• The application is PHP 8.3+ and Symfony-oriented (the 2.x line requires Symfony 7+, 2.1 allows Symfony 8). For a Laravel codebase, treat this as a reference implementation to vendor or wrap, not a drop-in — it is a Symfony bundle, and the Laravel path is extra glue you will own.
• Your need is genuinely narrow: detect a supported video URL and produce a canonical embed URL. No oEmbed metadata fetch, no thumbnails, no durations, no player analytics.
• You want zero license cost, small surface area, and you are comfortable pinning a version and reading the source (the README is thin; the real documentation lives off-repo, and the changelog is the most informative artifact).
• You can absorb upstream change: 2.0.0 removed videoType as a breaking change, and 1.0.2 renamed a provider type. Plan for semver-major churn and test around the parsed output.

Look elsewhere when:

• You need rich metadata (title, author, thumbnail, duration, aspect ratio) or provider API calls — you want an oEmbed/embed-metadata library instead.
• You need broad or niche provider coverage (TikTok, Dailymotion, Wistia, Loom, Peertube). You will be extending the provider set yourself.
• You need front-end concerns a PHP helper won't give you: responsive wrappers, consent/privacy gating (GDPR cookie walls), lazy-load facades, CSP-friendly markup. That's your design system's job.
• You need community support, security responsiveness, or an SLA. Zero stars and zero dependents means no ecosystem; if it breaks, you fix it. Acceptable for an internal tool, not for a platform-critical path.
• You are not on PHP/Symfony and would be porting the logic anyway.

Mitigation if adopted: fork or vendor the source, pin the exact version, and write your own characterization tests over the URL-parsing behavior you depend on, so an upstream release can't silently change parsed output.

How to Pitch It (Stakeholders)

For executives (one paragraph): "This is a small, MIT-licensed helper that handles one tedious thing well: turning a video link into a correctly formed embed. It removes some custom code from a feature we're already planning, costs nothing to license, and is deliberately narrow — so it is a modest efficiency, not a strategic investment. The main caveat is that it's a single-vendor library with essentially no external adoption, so we treat it as code we own: we pin a version and can maintain it ourselves if needed. I'd approve a short spike, not a commitment."

For engineering (one paragraph): "It's a Symfony bundle — a URL parser plus a VideoDetails value object exposing getEmbedUrl(). Don't expect sanitization, responsive markup, or metadata; those stay with us. For our Laravel app, the honest plan is a 1–2 day spike: pull the provider/parser classes, wrap them behind our own EmbedResolver interface, and add tests over the URL shapes we care about. If the spike shows the parsing rules are simple enough to reimplement, do that instead and skip the dependency. Either way we own the boundary."

Recommendation to record: Approve a timeboxed evaluation, not adoption; decide based on (a) how many providers we actually need, (b) whether we require metadata, and (c) whether we're willing to own a fork. Default to wrapping behind an internal interface so the package is replaceable.