Dogfooding @neurowire/core to power this blog's feeds
This site publishes its own Atom, JSON Feed, and NWF feeds from one canonical Neurowire model, because dogfooding your own library is the most honest test it gets.
The Atom, JSON Feed, and NWF links in this site’s footer are all produced by @neurowire/core, the same library the Neurowire docs describe. One canonical model serialises to all three formats at build time. I run my own library on my own blog because that is the fastest way to find out where it actually hurts.
mederic.me is a static Astro site. There is no server, no feed plugin, and no hand-written XML. At build time the site collects its posts, builds one Neurowire model, and asks that model to emit each feed format. If the library is wrong, my own feeds break first, and I notice before anyone else does.
How does a static site build a feed model?
The flow is short. Astro hands me the writing collection, I map each post into the canonical shape Neurowire expects, and I construct a single NeurowireFeed model from that list. That model holds the feed metadata and the entries once, with no format-specific assumptions baked in.
From there it is three calls. toAtom() gives me the Atom XML, toJsonFeed() gives me JSON Feed, and toNwf() gives me the native Neurowire format. Each one is a pure serialisation of the same source, so the three endpoints can never disagree about what was published.
Why is one canonical model the point?
Most sites generate feeds independently, so the Atom and the JSON Feed quietly drift. A date format differs here, an entry is missing there, and nobody notices until a reader’s reader complains. When every format is a projection of one model, drift is structurally impossible. There is nothing to keep in sync because there is only one source.
That is the whole thesis behind the Neurowire project: model your feed once, serialise it anywhere. The docs describe that canonical model in full, and this blog is the proof that it works in a real static build.
Why is dogfooding the best test?
Tests check the cases you thought of. Running the library on your own live site checks the cases you did not. When I add a post and the build emits three correct feeds, that is a stronger signal than any unit test, because it exercises the real Astro pipeline, real content, and real edge cases in titles and dates.
It also keeps me honest about ergonomics. If building the model is annoying for me, it is annoying for every other user, and I feel that friction immediately. A library you use daily cannot hide a clumsy API from its own author.
What did dogfooding surface?
The honest answer is the small things: a date that needed normalising, an empty-summary case, the exact shape Astro hands you for a collection. None of it was dramatic, and all of it would have shipped unnoticed if my own feeds were not on the line. That is exactly why I built it this way, and why the launch write-up leans on the same model. The best test for a feed library is a real feed you actually read. You can build and read your own in the Neurowire App.