Laravel Feeds Laravel Package

Product Decisions This Supports

• Channel expansion bets. If the roadmap includes selling through marketplaces or price-comparison engines, this package shortens the path from "we have a catalog" to "we publish a feed." It targets the serialization layer, not the whole channel integration.
• Build vs buy for feed generation. The alternative is writing your own XML/CSV serializers, chunked queries, URL mapping, and per-channel validation. That work is boring and repetitive. A small MIT package turns it into a dependency instead of a backlog item. The buy side is cheap; the cost is ownership risk, not license cost.
• Make the catalog a product asset. Feeds force a clean, stable contract over product data: identifiers, availability, prices, images, categories. That contract is useful beyond one channel — it hardens your data model.
• Decouple export from the request cycle. The package is framed around large exports. Release 2.0.0 strengthens this claim: the changelog references "export batches," export batch capacity versus split-feed capacity, and fixes for per-row diagnostic path resolution and quadratic ownership lookups when publishing split feeds. That is evidence of a real batched export path being exercised at scale, not just a README promise. It does not prove memory behavior on your catalog; see verification below.
• Per-channel mapping as configuration, not code. New per-feed converter configuration attributes, per-item date format attributes, and title-derived slugs move channel-specific formatting into config. PM-relevant: adding a second or third channel becomes a configuration and QA task rather than a code branch, which changes the cost estimate for "test another channel."
• Feature scoping for a single channel. A targeted feed recipe is a small, time-boxed feature. You can ship one channel, measure conversion and revenue, then decide whether to invest further or stop.
• Platform upgrade dependency. 2.x prepares for PHP 8.4, Laravel 13, and Pest 5, with a documented 1.x → 2.x upgrade guide. This package now couples your feed roadmap to a major framework upgrade. If the application is not on Laravel 13-era tooling, adopting 2.x is not a one-day dependency add — it is a platform project. Decide that at the portfolio level, not inside the feed feature.
• Output contract change to flag. The "Feed" suffix was removed from feed titles, and feeds can now be generated by title-derived slugs. If downstream channels, filenames, URLs, or stored feed identifiers depend on the old naming, this is a user-visible change. Budget a mapping check, not just a composer bump.
• Not a platform decision. This does not support multi-tenant feed management, per-merchant configuration, or vendor SLAs. Those are different products.

Verification needed before this drives a decision: confirm batched exports keep memory bounded on a catalog sized like ours (the 2.0.0 performance fixes are encouraging but are the maintainer's benchmarks, not ours). Confirm the 1.x → 2.x upgrade guide covers the naming and slug changes. Check the Laravel 13 requirement against our actual application version, and check Packagist directly — earlier release metadata had a date inconsistency. [unverified] Star count, dependent count, and test coverage as of this review.

When to Consider This Package

Consider it when all of these are true:

• The application is already Laravel and can move to the 2.x baseline (PHP 8.4, Laravel 13), or you are willing to pin 1.x and forgo fixes.
• Catalog data lives in Eloquent models or a database this package can query.
• You need one to three feed formats, not a catalog of twenty. The new per-feed converter configuration makes two or three cheap; it does not make twenty free.
• Feed generation can run as a scheduled job or queue worker, not inside a user request.
• Someone on the team can read the source. The project is still small — you are effectively adopting a library you may have to maintain. Budget for that.
• The failure mode is tolerable. A stale or malformed feed loses marketplace listings for a while. It does not corrupt orders or payments.

Look elsewhere when:

• You need a managed service with uptime guarantees, monitoring, and per-channel mapping maintained by a vendor.
• The stack is not Laravel, or cannot reach the 2.x framework baseline and you are unwilling to run a pinned, aging 1.x.
• Catalog data is not reachable through Eloquent without significant glue code.
• The catalog is very large and the export must run as a distributed pipeline. A dedicated export service is the better shape; a package inside the app becomes a bottleneck and an operational liability.
• You need many channel formats with frequently changing specs. That is a mapping-maintenance problem, and one maintainer with a small user base is not a reliable source of spec updates.
• Procurement requires a security review, an SBOM trail, or a named support contact.

The honest framing: this is a convenience library, not infrastructure. Adopt it to save a week, and expect to own the code. The 2.0.0 release is a good sign — active maintenance, real performance work, an upgrade guide — but a major version tied to a major framework version also means the maintenance cost lands on you on the framework's cadence, not yours.

How to Pitch It (Stakeholders)

To executives: There is a low-cost way to test a new sales channel. The library is MIT-licensed, small, and fits the existing Laravel codebase, so the experiment costs engineering days rather than a new service or a vendor contract. The new release makes multi-channel mapping a configuration exercise and includes performance work aimed at large catalogs, which is the direction we want. Two caveats. First, the new major version targets the next major Laravel release, so there is a platform prerequisite — if we are not ready to upgrade, this becomes a larger project than it looks. Second, the project is still maintained by essentially one person, so we should assume we may need to patch it ourselves. That is a reasonable trade for a channel test, not for a core revenue dependency.

To engineering: One responsibility — turning models into feed documents for external consumers. It keeps feed logic out of controllers and gives us a single place to handle batching, field mapping, and per-channel formats. 2.0.0 adds per-feed converter attributes, per-item date formats, and title-derived slugs, so channel differences live in config. It also changes the output contract: the "Feed" title suffix is gone and slugs now drive naming, so audit any stored identifiers or downstream consumers before upgrading. The concerns are unchanged and worth naming up front: single maintainer, small dependent base, no guarantee of timely spec updates, and a required jump to PHP 8.4 / Laravel 13 with Pest 5. Treat it as vendored code. Read the source, verify memory stays bounded on a catalog our size, work through the published 1.x → 2.x upgrade guide, and pin the version. If we adopt, wrap it behind our own interface so a fork or replacement stays a contained change.