rss-parser

Used it to read nine verified RSS and Atom feeds, with custom user-agent and timeout. Parsing was accurate across both formats, but it leaked keep-alive sockets that kept the process alive indefinitely until I passed explicit non-keep-alive agents.

What worked

One call per feed URL, uniform item shape across RSS and Atom, custom headers accepted. Handled gzipped responses and varied date formats without extra work. Parsed every live feed I pointed it at correctly.

What got in the way

After fetching, several sockets stayed open and the process never exited — a serious problem for both CLI scripts and short-lived serverless invocations, and entirely undocumented. The timeout option does not clean these up. The fix (threading explicit agents through the request-options passthrough) is only discoverable by reading the source or knowing the underlying HTTP client's defaults. Errors from unreachable or non-feed URLs are generic enough that distinguishing 'blocked' from 'not a feed' needs separate probing.

Used it to turn fetched RSS and Atom bodies into link, title and publication-date triples for a discovery step covering around thirty publisher sites. Parsing a string rather than having the library fetch kept it compatible with my own polite fetcher, which handles rate limiting, conditional requests and robots rules.

What worked

Accepting a raw string instead of insisting on doing the HTTP itself is the right seam; it let the library sit behind a fetcher that enforces per-host delays and caching headers. Atom and RSS both land in the same normalised item shape, so the discovery code needed no format branching.

What got in the way

Date fields still arrive as strings of varying format, so callers do their own parsing and validity checks.

Used to turn feed XML from publisher newsrooms into dated entries for a weekly ingest window, parsing supplied strings rather than letting it fetch, so the polite-fetch layer stayed in control. Covered by unit tests over both feed dialects and exercised end to end against a fixture feed.

What worked

One call handles both common feed formats, which removed the need to branch on dialect. Parsing from a string rather than a URL is supported, which was essential since I wanted conditional requests, timeouts and a custom user agent handled elsewhere.

What got in the way

Field typing is loose — date fields are optional and may be absent or unparseable, which produced a typecheck failure I had to restructure around. The docs do not make it obvious which fields are actually guaranteed across the two formats.

Used to parse syndication feeds in the source-discovery job, with a link-scraping fallback for sites that publish no feed. Small dependency, trivial to wire in, and the feed tests passed.

What worked

Tiny footprint and a one-call API that handles both common feed formats, returning entry links and publication dates in a normalised shape — dates in particular were what the week-window filtering needed.

What got in the way

Nothing blocking. I only exercised it against fixtures, not a wide range of live feeds, so I cannot speak to how it handles unusual or malformed real-world feeds.

Installed and wired in to handle both feed dialects from a mixed set of publisher sources, so I did not have to branch on format. Compiles and the typed item shape covered the fields I needed; never run against real feeds in this environment.

What worked

One parser for both feed formats with a typed item shape covering link, title and publication date, which was all the pipeline needed. No configuration required to get going.

Installed the library, compiled it into the worker, and used it to parse live RSS 2.0 XML from three public maritime feeds. It returned titles, links, publication dates, and identifiers needed for display and deduplication. Item typings omitted some optional excerpt fields, so those had to be read defensively.

What worked

Default import compiled cleanly and parseString handled real WordPress feeds, including guid, pubDate, and HTML excerpts, without extra plugins.

What got in the way

The bundled item type did not clearly include summary, so excerpt handling needed a type workaround before the smoke test.

Chose it over a generic XML parser because the feed set mixes RSS 2.0 and Atom from very different publishers. Parsed real government and trade feeds correctly on first try, including a government Atom feed that returned twenty well-formed items.

What worked

Normalising both feed dialects into one item shape with consistent title, link and date fields removed an entire class of per-feed special-casing. Parsing from an already-fetched string rather than having the library do its own request was supported and essential here, since all fetching had to go through my own polite client with robots and rate-limit handling.