Vimeo Bundle Laravel Package

Product Decisions This Supports

• Video: build vs. buy. This package sits on the "buy/host with Vimeo" branch of the video decision. It is a thin API adapter, not a platform — evidence that the integration cost is small and the real cost is vendor dependency, not engineering effort.
• Shaping the upload/UGC spec. It documents the flow your product spec needs regardless of vendor: authenticated app credentials, ticket-based resumable uploads, async transcoding with a "processing" state, post-upload metadata (title, description, privacy, embed presets), and playback URLs. Use it to write acceptance criteria, not to ship code.
• Privacy and entitlement modeling. Vimeo's privacy tiers (public, unlisted, password, domain-restricted, embed-only) map onto subscription gating, internal training libraries, or paid course content. This is a pricing-tier and permissions decision, and it must be made before the integration is scoped.
• Scope estimation for a spike. Treat the bundle as a checklist of the Vimeo v3 endpoints a typical product needs — upload, status polling, folders/projects, thumbnails, embed settings — and size the work from that list.
• Not an adoption decision for a Laravel codebase. It is a Symfony 2 bundle; Symfony 2 is end-of-life. There is no supported path into Laravel. Do not let it anchor a build plan or appear on a technical roadmap.
• Roadmap hygiene input. If it turns up in a dependency audit or an inherited codebase, that is a signal of an unowned, unmaintained integration that needs a replacement plan or removal.

When to Consider This Package

Consider it only in a narrow, non-production sense:

• You are maintaining a legacy Symfony 2 application that already depends on it and you are planning migration, not expansion — and even then, evaluate vimeo/php-sdk first.
• You want a read-only reference for the upload, privacy, and embed-setting flows while writing a spec or spike. Read the code; do not install it.

Do not consider it when:

• You are on Laravel. A Symfony bundle is not a supported extension mechanism in Laravel — the value is in the service-container wiring, which is precisely what does not port.
• You need maintained code. Zero stars, zero dependents, no downstream users, and a Symfony generation two majors behind. There is no community to absorb a Vimeo API change and no security response.
• Runtime modernization applies. Symfony 2-era constraints pin you to end-of-life PHP, which alone fails most security and hosting policies.
• You need more than basic CRUD to Vimeo — live events, player customization, analytics ingestion, webhooks. A thin wrapper from that era will not cover the current API and no one but you will extend it.
• Vendor-risk review applies. A bus factor of effectively zero disqualifies it from any customer-facing path.

Recommended alternative: vimeo/php-sdk (official, framework-agnostic, callable from Laravel behind a thin service provider) or Vimeo's REST API directly behind your own interface, so the vendor stays replaceable.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated requestlab/vimeo-bundle as a way to add video to the product and recommend against adopting it. It is a Symfony 2 bundle built for a framework generation that reached end of life years ago, with no stars, no dependent projects, and no maintainer activity — so any integration we build on it becomes ours to own permanently and will break the first time Vimeo changes its API. The useful output of this evaluation is not the code but the decision it clarifies: video hosting is a buy, not a build. If video is on the roadmap, the correct path is Vimeo's officially maintained PHP SDK, or direct REST calls behind our own internal interface that keeps the vendor swappable. Budget a small, time-boxed spike — roughly one to two weeks for upload, playback, and a privacy tier — and treat ongoing video hosting as a vendor line item, not engineering headcount.

For engineering (short): Do not pull this in. It is a Symfony 2 bundle — wrong framework, EOL runtime constraints, no maintenance signal, and a Composer conflict with modern Illuminate components is the expected outcome. Use it as a reference for the upload-ticket and privacy/embed-setting flows if useful, then implement against vimeo/php-sdk behind a VideoProvider interface in our own code so we can swap to S3 plus a transcoder or another vendor later. Two design notes worth carrying over: track videos by our own ID with the provider ID as a foreign key (never the reverse), and model upload status as an async state machine because transcoding is not synchronous.

For product (short): The bundle confirms what a minimum viable video feature requires — authenticated upload, asynchronous processing with a visible "processing" state, privacy and entitlement rules, and embeddable playback. Plan the UX for the wait between upload and playable, decide up front which content is public, unlisted, or domain-locked (that choice drives the pricing model and the integration spec), and route uploads through a background job so a Vimeo slowdown degrades a queue rather than a user session.