feat(rss): styling for the webview

[aarnphm]

ofc you should use a reader aggregator for your own rss feed, but we should have a default view for these

Example from my end with the feed.xsl

also might be worth to think about supporting atom

[aarnphm]

cc @bfahrenfort

[saberzero1]

We currently generate the RSS ourselves. We could consider using a package to generate both RSS and Atom (and possibly other formats.)

A few possible candidates:

• https://www.npmjs.com/package/rss
• https://www.npmjs.com/package/feed

[aarnphm]

that's fine tbh, I think we can still just generate the feed ourselves (it is just a string format in most cases :))

[bfahrenfort]

Like you say, RSS and Atom are semantically different but exactly the same thing. It doesn't make much sense to generate both, anything that supports RSS also supports Atom. When I started contributing to Quartz, contentIndex was generating a broken Atom that failed validation, I just converted it to RSS because that was what I knew at the time. If we want to convert the feed code to Atom instead of RSS it's extremely easy, I just don't really see a point. (Maybe on top of my PR, add a bool in the options for RSS vs Atom and write corresponding generateAtomEntry and finishAtomFeed, with conditionals to generate either based on the switch?)

Now, there is a very niche new contender which works in JSON, that looks interesting, but I'm not terribly interested in advocating for the expansion of a niche within a niche... JSON Feed

Re: styling, I actually played around with creating an xsl style for quartz, but it has the major disadvantage of breaking mimetypes for people who have set up their RSS readers to automatically open RSS links in the reader (it will always open in the rendered browser view instead).

RSS and Feed on npm both pull in pretty significant dev dependency trees, they would never be merged lol

[saberzero1]

Like you say, RSS and Atom are semantically different but exactly the same thing. It doesn't make much sense to generate both, anything that supports RSS also supports Atom. When I started contributing to Quartz, contentIndex was generating a broken Atom that failed validation, I just converted it to RSS because that was what I knew at the time. If we want to convert the feed code to Atom instead of RSS it's extremely easy, I just don't really see a point. (Maybe on top of my PR, add a bool in the options for RSS vs Atom and write corresponding generateAtomEntry and finishAtomFeed, with conditionals to generate either based on the switch?)

Now, there is a very niche new contender which works in JSON, that looks interesting, but I'm not terribly interested in advocating for the expansion of a niche within a niche... JSON Feed

Re: styling, I actually played around with creating an xsl style for quartz, but it has the major disadvantage of breaking mimetypes for people who have set up their RSS readers to automatically open RSS links in the reader (it will always open in the rendered browser view instead).

RSS and Feed on npm both pull in pretty significant dev dependency trees, they would never be merged lol

Gotta love the irony of the RSS feed link on the JSON feed site.

Anyway, I'm not sure I understand what you mean with significant dev dependency trees. NPM dependencies only pull in their transitive dependencies, not their transitive dev dependencies. This would mean 1 or 2 packages in this case.

[bfahrenfort]

I had assumed that when you add a package as a dev dependency it would pull in its own dev dependencies.

And yeah, pretty funny that they don't eat their own dog food even partially lol (edit: they do have a json feed on their site, so much for my fun)

[saberzero1]

I had assumed that when you add a package as a dev dependency it would pull in its own dev dependencies.

And yeah, pretty funny that they don't eat their own dog food even partially lol (edit: they do have a json feed on their site, so much for my fun)

Dev dependencies are for when you want to do development on the package. So you should only install dev dependencies when you are developing the package in question.

Just like if you work on Quartz, you would npm install --include=dev in order install all the type definitions for your LSP to be able to give you warnings, errors, and type validations in your editor. None of these are in the final production build.