Feed Parser Laravel Package

Product Decisions This Supports

• Feed ingestion features: any roadmap item that requires pulling in RSS or Atom content — a "latest from the blog" widget, an internal news aggregator, a competitor/content monitoring dashboard, a customer-facing syndication reader, or an onboarding flow that imports a user's existing content feed.
• Build vs buy: this is the "buy" (well, adopt) answer to a narrowly scoped problem. It replaces hand-rolling XML parsing, date normalization, and RSS/Atom format differences in-house. The build cost avoided is small but non-trivial — a week or two of engineering plus ongoing edge-case maintenance.
• MVP and prototype scope: useful where speed matters and feed parsing is supporting infrastructure rather than the product. Low switching cost if it proves insufficient, because a well-wrapped parser is easy to replace.
• Explicitly does not support: podcast feeds with enclosures and iTunes namespaced tags, Media RSS, JSON Feed, complex third-party XML extensions, or feed generation/syndication output. If the roadmap item is "build a podcast player" or "publish our own feed," this package is not the answer and should not be scoped as if it were.
• Risk posture: adopting a 0.0.1 dependency is a deliberate bet on a young library. It should not underpin a revenue-critical or contractually-guaranteed pipeline without an abstraction layer and a fallback plan.

When to Consider This Package

Adopt when all of the following hold:

• The stack is Laravel/PHP and the team prefers a native, framework-idiomatic dependency over a general-purpose XML library.
• Requirements are confined to reading standard RSS and Atom — titles, links, dates, content — with no namespaced extensions, enclosures, or media handling.
• The feature is early-stage, internal, or otherwise tolerant of occasional parsing gaps.
• The team is willing to pin the version, wrap it behind a small internal interface (e.g. FeedReader), and write contract tests around real-world feed fixtures.
• Someone is available to monitor the repository — a single-maintainer package at 0.0.x carries a bus-factor and abandonment risk that needs an owner.

Look elsewhere when:

• Stability is contractual. 0.0.1 means the public API can change or disappear without a major-version signal. SemVer gives you no protection here.
• Feed breadth matters. Podcasts, Media RSS, content:encoded, Dublin Core, JSON Feed, or malformed-feed tolerance all fall outside "basic support for RSS and Atom." A more established parser is the safer choice.
• You need to produce feeds, not just consume them — this is a parser only.
• You need SLAs, security responsiveness, or long-term support. A solo-maintained 0.0.1 package has no such guarantees; treat it as code you may eventually have to fork.
• Feed parsing is core product surface (e.g. the aggregator is the product). Then the parsing layer deserves a dependency with a track record.

How to Pitch It (Stakeholders)

For executives: We can support feed-based features without building a parser. This package handles the standard RSS and Atom formats, which covers most blogs and news sources, and lets us ship an ingestion feature in days rather than weeks. The trade-off is maturity: it is a brand-new, single-maintainer, pre-1.0 library. That is acceptable for a scoped, non-critical feature provided we isolate it behind our own interface so it can be swapped without rework. Recommend approving for prototype/internal use and revisiting before it touches anything customer-critical or revenue-bearing. The cost of being wrong is low; the cost of building it ourselves is higher and permanent.

For engineering: Small Laravel package, 0.0.1, basic RSS + Atom parsing. Treat it as an unstable dependency: pin the exact version, wrap it behind a narrow internal interface, and cover it with fixture-based tests against real-world feeds (including a deliberately malformed one) so a swap is a one-file change. Validate early against the actual sources we care about — if any of them use podcast enclosures, content:encoded, or other namespaced tags, this package will not cover them and we should know that before committing. Do not let it leak into domain code; parsing output should be normalized into our own value objects at the boundary.