Rss Feed Collect Bundle Laravel Package

Getting Started

• Install with composer require tourze/rss-feed-collect-bundle. Note the name: this is a Symfony bundle, not a Laravel package. It will not register itself via Laravel's package discovery, and there is no publishes() / service provider contract to lean on.
• Read, in this order: composer.json (PHP version, whether it pulls symfony/http-client, symfony/framework-bundle, or a feed parser such as laminas-feed), the <Name>Bundle class in src/, then anything under src/Command, src/Service, and src/Resources/config. Those three locations tell you what you can actually call and what you'd have to wire yourself.
• Confirm the transport before writing code. If the bundle depends on Symfony's HttpClientInterface, your Http::fake() calls in tests will not intercept it — see Gotchas.
• First use case, in order of least surprise: take a single hard-coded feed URL, invoke the collector once from php artisan tinker, dump the result, then wrap it in a queued job. Do not start with scheduling; get one feed into one table first.

Implementation Patterns

• Bridge it, don't fight it. Create a small RssFeedCollectServiceProvider that binds the bundle's collector/parser interfaces to their concrete classes, and expose a thin FeedCollector wrapper class as your app-facing API. Everything else in your codebase should depend on your wrapper, not on the bundle's namespace — that keeps a 0.0.x dependency contained to one file when the API shifts.
• Config lives in your app, not the bundle. Symfony bundle config normally flows through a Configuration + Extension pair, which Laravel doesn't execute. Port the meaningful keys into config/rss-feed-collect.php and inject them into the wrapper's constructor.
• Queue per feed. One job per feed URL, with $tries = 1 and a short retryUntil. A malformed feed should fail its own job, not abort a batch of twelve. Trigger the fan-out from a single scheduled command.
• Persist raw before normalised. Store the fetched XML (or the parser's item array as JSON) alongside a normalised feed_items row with a unique index on (feed_id, guid) falling back to (feed_id, link). Feed GUIDs are frequently absent, duplicated, or reused after edits; dedupe at the database, not in PHP.
• Treat date parsing as hostile. RSS uses RFC 822, Atom uses RFC 3339, and plenty of feeds get both wrong. Normalise through Carbon::parse() with a try/catch and store a nullable published_at rather than dropping the item.
• Scheduling. $schedule->job(new CollectFeeds)->hourly()->withoutOverlapping() is the whole integration. Add a per-feed last_fetched_at and skip feeds still inside a polite interval (5–15 min) regardless of schedule.
• Testing. Mock whatever HTTP abstraction the bundle actually uses — bind a fake client into the container rather than reaching for Http::fake(). Keep three fixture files checked in: one RSS 2.0, one Atom, one deliberately malformed.

Gotchas and Tips

• 0.0.1 is the first tag and the changelog carries no prose. The release notes are only a compare link, so there is no documented feature list, no BC promise, and no migration guidance. Read the actual diff before adopting, and pin the exact version ("tourze/rss-feed-collect-bundle": "0.0.1") rather than a caret constraint. Assume any 0.0.x bump can break your wrapper.
• Semantic-versioning expectations do not apply. Under 0.x, minor bumps are conventionally allowed to break. Budget for re-reading the wrapper every time you update.
• No Laravel auto-discovery. Expect to register services manually. If the bundle's services reference Symfony-specific interfaces (EventDispatcherInterface, LoggerInterface), you may need Laravel's PSR-3 logger bound, or an adapter class; Symfony's EventDispatcherInterface in particular is not Laravel's dispatcher and is a common failure point.
• HTTP client mismatch. Http::fake() and Http::preventStrayRequests() only cover Laravel's Guzzle-backed client. If the bundle uses symfony/http-client, your tests will make real network calls unless you bind a stub implementation of HttpClientInterface. Verify this early — it's the single most likely source of flaky CI.
• Parsing edge cases to expect: CDATA-wrapped HTML in <description>, mismatched content encodings, <link> that is relative rather than absolute, and Atom <link rel="alternate"> versus <link rel="self">. Sanitise description HTML before rendering, never after storage.
• Politeness and failure. Set explicit connect/read timeouts and a User-Agent; several publishers reject requests without one. Log the raw response body at debug level before parsing so a parse failure is diagnosable after the fact.
• Extension points to look for: a replaceable collector service (bind your own implementation), a parser interface you can decorate to add field normalisation, and any Symfony events that you can bridge into Laravel listeners. If none of these exist in 0.0.1 — and at this version they may not — plan on forking or vendoring rather than monkey-patching.
• Debugging order of operations: invoke the collector once synchronously outside the queue, with the raw body dumped to a log channel. Most failures at this stage are wiring failures (services not bound), not parsing failures, and the stack traces point at the container rather than the feed.