Social Post Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. reference-implementation decision for multi-channel publishing. This package is still not adoptable as a dependency. The new v3.1.0 release is housekeeping only — it drops Symfony <3.4/<4.3 and PHP 7.1, raising the floor to roughly PHP 7.2+ / Symfony 4.3+. It adds no features, no network API refresh, and no Laravel support. Treat it as a design reference for how a unified "post once, fan out to N networks" abstraction looks, not as a vendor choice.
• Scoping a cross-posting / social distribution feature. The core domain model (one message object → per-network adapters for Facebook, LinkedIn, Twitter) still maps directly to the product story: compose once, publish everywhere, return per-network results. Use it to size the work: three adapters, credential management, per-network character/media constraints, and partial-failure handling.
• Framework fit. Still a Symfony bundle, not a Laravel package. The v3.1.0 floor (Symfony 4.3) sits below what any current Laravel release ships against — Laravel 9+ pulls Symfony 6 components, Laravel 11 requires PHP 8.2+. For a Laravel roadmap this remains a signal to look at Laravel-native options or a thin in-house service, not to plan an integration sprint.
• Roadmap risk input. Any plan that assumes "the library handles the APIs" is invalid here. Facebook Graph versions, LinkedIn's API scopes, and Twitter's v1.1→v2 migration have all moved since 2020, and v3.1.0 touches none of them. Budget for owning the API contract yourself.
• Dependency-maintenance signal. A version bump with no changelog beyond platform floors is the classic "kept alive enough to install, not enough to rely on" pattern. Weigh it as evidence of low but nonzero activity, not as a revival — verify release cadence and issue responsiveness before treating the project as maintained.
• Use cases it validates (not delivers): marketing/announcement syndication, support-ticket-to-social escalation, changelog distribution, CMS publish hooks, internal comms fan-out.

When to Consider This Package

Consider it only as a reading reference when:

• You are designing your own publishing abstraction and want a cheap prior for interface shape (message DTO, per-provider adapter, aggregated response).
• You are on Symfony 4.3/5-era code and need to understand a legacy integration you are about to replace — not extend. v3.1.0 makes it installable on those versions; it does not make it safe to build on.
• You need a 30-minute spike to confirm scope for a build-vs-buy conversation.

Look elsewhere or build in-house when:

• You are on Laravel. The bundle targets Symfony's DI container, bundle registration, and event system. The v3.1.0 floor is well behind current Laravel's Symfony/PHP requirements, so bridging is still more work than writing the three adapters.
• You need maintained API compatibility. The platform bump does not change that the last functional/API work was 2020: assume no security patches for the integration layer, no PHP 8.1+ guarantees, and known-broken OAuth flows for at least Twitter. Hard blocker for production.
• You need reliability features: retries, rate-limit backoff, idempotency, per-network partial failure, media upload, scheduling, webhooks, or audit logging. None of that is here — and none of it arrived in v3.1.0.
• You want managed OAuth. Consider a hosted aggregator (Ayrshare, Buffer/Publer API, Postiz) or first-party SDKs per network. Compare total cost: three OAuth lifecycles + token refresh + API version churn against a per-post vendor fee.
• Compliance or data residency matters. Cross-posting routes content through third parties; a self-hosted in-house adapter keeps the data path in your control.

How to Pitch It (Stakeholders)

Bottom line: do not adopt; mine it for design and buy or build instead. The new v3.1.0 release does not change this.

For executives: The candidate library cross-posts a single message to Facebook, LinkedIn, and Twitter — the feature we want. It is a Symfony bundle whose only recent release (v3.1.0) raises minimum PHP/Symfony versions and nothing else. No new networks, no API updates, no reliability work. Every social API it targets has changed since 2020, so adopting it means inheriting unmaintained OAuth and expired API versions on day one. Recommendation: fund a small build (or a paid aggregator subscription) for the publishing capability; spend a day reviewing this repo to reuse its interface shape and avoid re-deriving the problem.

For engineering: It remains a clean, small reference for a message-DTO-plus-per-provider-adapter pattern, and useful for scoping. v3.1.0 is a compatibility bump (drops PHP 7.1 and Symfony <3.4/<4.3) — it does not add retry/rate-limit/media handling, does not modernize the SDKs, and still doesn't target Laravel. Plan on owning three OAuth flows and their token refresh; treat network API versioning as an ongoing operational cost, not a one-time integration.

Cost framing: Option A — in-house adapters: ~1–2 engineer-weeks for v1 across three networks, plus ~1–2 days/quarter for API drift. Option B — aggregator: near-zero build, per-post or monthly fee, less control. Option C — this package: ~$0 license, unbounded and unquantifiable integration and breakage risk. C is not a real option.