Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Symfony2 Stream Response Laravel Package

nercury/symfony2-stream-response

Symfony2 Stream Response adds a simple streamed response type to Symfony 2, enabling applications to send large files or dynamically generated content to the client incrementally instead of buffering the full output in memory. Useful for downloads, exports, and real-time data.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Framework-fit triage. This is a Symfony2 bundle, not a Laravel package — so its first product value is negative signal: it should not factor into Laravel roadmap decisions at all, and any team that found it via a "Laravel packages" list should treat that as a discovery-quality problem worth fixing in your internal package shortlist.
  • Build vs. buy for streaming responses. Useful as a reference point when scoping features that need chunked/progressive output: large CSV or report exports, memory-safe file downloads, progress-style endpoints, and long-running jobs that would otherwise blow PHP's memory limit or time out.
  • Legacy Symfony 2.x sustainment. If you own a Symfony 2 app, this informs the "keep the lights on vs. migrate" call — the answer here leans strongly toward migrate, because the capability it wraps now ships in the framework itself.
  • Dependency-risk accounting. Zero stars, zero dependents, no release signal: this is a supply-chain liability line item, not a capability line item. It supports a "remove or vendor" decision, not an "adopt" one.
  • Not supported: it does not de-risk any forward-looking roadmap item. There is no active upstream to bet a feature on.

When to Consider This Package

Consider it only in this narrow case:

  • You maintain a Symfony 2.x application that already has this bundle installed, and you need to understand or temporarily preserve existing streaming behavior while you plan a migration.
  • You want a historical reference implementation of streamed responses for a design discussion — read the code, do not depend on it.

Look elsewhere — decisively — if any of the following hold:

  • You are on Laravel. Use response()->stream() / response()->streamDownload(), which wrap Symfony's StreamedResponse through HttpFoundation. No third-party bundle required.
  • You are on Symfony 3.4+ or any supported 4.x/5.x/6.x/7.x release. Use Symfony\Component\HttpFoundation\StreamedResponse directly. It is maintained, tested, and already in your dependency tree.
  • You need real-time push (SSE at scale, WebSockets, fan-out). Use Mercure (Symfony ecosystem), Laravel Reverb/Echo, or a dedicated message broker. A streamed HTTP response is not a pub/sub transport and will not survive PHP-FPM worker limits gracefully.
  • You need operational guarantees — SLA, security patching, PHP 8.x compatibility, framework version constraints. None of that is available here.
  • You need anything with a maintenance contract. Zero dependents and zero stars means no community backstop, no CVE response, and no upgrade path you don't personally own.

Evaluation criteria to apply to any streaming dependency, for the record: supported PHP and framework version ranges, release cadence and last-commit recency, test coverage, open security advisories, and whether the capability is already in the framework you pay for.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Remove if present. Do not budget for it.

For executives: This is a thin, unmaintained wrapper around functionality that Symfony has shipped natively for years. It has no users, no releases of consequence, and no maintainer capacity to respond to a security issue. Adopting it would add third-party risk in exchange for zero capability we don't already have. Cost to avoid it: nothing. Cost to remove it later: a small engineering task inside an existing sprint.

For engineering: The bundle predates StreamedResponse being the standard answer, and it targets Symfony 2 — a version line that is end-of-life. For Laravel services, response()->stream() and streamDownload() cover the same ground with first-party support. For Symfony services, use HttpFoundation\StreamedResponse directly. If a streaming endpoint currently depends on this bundle, the migration is a contained refactor of the response construction — no data model or API contract change, so it can ride along with routine maintenance rather than needing its own initiative.

Bottom line: treat this as a known-obsolete pattern, not a candidate dependency. The product decision it drives is a one-line cleanup task and a note in your package intake checklist to filter out abandoned Symfony2-era bundles before they reach evaluation.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
frankyso/ipaymu
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator