fix: filter out draft item from glob result

[equt]

Changes

• This PR should fix @astrojs/rss includes drafts in output #5505
• In brief, RSS will now respect the draft in the Markdown/MDX frontmatter

Testing

A corresponding test has been added to ensure that any Markdown/MDX has draft: true in its frontmatter will be ignored, and a missing one or false will not.

Docs

I'm not sure if this is a new feature or just a fix. Maybe we should add a note in the RSS doc?

/cc @withastro/maintainers-docs

[changeset-bot]

🦋 Changeset detected

Latest commit: a138bdc

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[delucis]

Thanks @equt.

Could we make this configurable via an option to the rss() function? Or perhaps follow the top-level markdown.drafts option although not sure we can easily access that in this context.

I know some people like to do stuff like include drafts when running astro dev to test stuff out, but exclude them in astro build, so making this configurable would support that use case.

[equt]

Agree with that, but I can't figure out a way to get that option in the top-level config unless we parse the astro.config file again in the RSS package.

🤔 How about we take a step back instead? Rather than filtering for the user, we expose the draft in the RSSFeedItem. This would allow something like a preview mode for previewing draft posts, and release mode for excluding all drafts.

import rss from '@astrojs/rss';

const postImportResult = import.meta.glob('../posts/**/*.md', { eager: true });
const posts = Object.values(postImportResult);

export const get = () => rss({
  title: 'Buzz’s Blog',
  description: 'A humble Astronaut’s guide to the stars',
  site: import.meta.env.SITE,
  items: posts.map((post) => ({
    link: post.url,
    title: post.frontmatter.title,
    pubDate: post.frontmatter.pubDate,
  })).filter((post) => {
    switch (import.meta.env.MODE) {
      case 'production':
        return !post.draft
      default:
        return true
    }
  })
});

[fflaten]

Agree with that, but I can't figure out a way to get that option in the top-level config unless we parse the astro.config file again in the RSS package.

🤔 How about we take a step back instead? Rather than filtering for the user, we expose the draft in the RSSFeedItem. This would allow something like a preview mode for previewing draft posts, and release mode for excluding all drafts.

There's really no need to expose anything in RSSFeedItem, is it? You can already get draft directly from frontmatter. Ex.

const postImportResult = import.meta.glob('./posts/**/*.{md,mdx}', { eager: true });
const posts = Object.values(postImportResult).filter((post) => import.meta.env.DEV || !post.frontmatter.draft);

If anything, I'd personally prefer RSSOptions to have a includeDrafts-bool like @delucis suggested. However, having content collections in mind, filtering gets even easier (see below), is accessed using data vs frontmatter and users might rename draft to isDraft etc. So maybe not the best time to hardcode a filter at all, but rather include steps in docs? 🙂

const posts = (await getCollection('blog', ({ data }) => {
    return import.meta.env.DEV || !data.draft
  }));

[equt]

There's really no need to expose anything in RSSFeedItem

Indeed, we don't need to expose the draft again, and somehow I just missed that.

users might rename draft to isDraft etc

Considering the markdown integration has already hardcoded this, I guess most users will just go with it.

So maybe not the best time to hardcode a filter at all, but rather include steps in docs?

We have to do something by default. Users who have put the draft: true in their posts will always expect the draft content to be filtered out.

[delucis]

Fair enough if we can’t get the top-level Markdown config option.

In that case I’d still suggest adding an option to the getRSS() function, so you could do:

import rss from '@astrojs/rss';

export const get = () => rss(
  drafts: true, // Include drafts
  // other options ...
});

[delucis]

Nice! LGTM — thanks @equt 🙌

Would love a second opinion from the core team on whether this is in fact a major bump (the safe choice) or if we can get away with calling this a bug fix.

[bholmesdev]

nit: I'd prefer the name includeDrafts for naming a boolean option

[delucis]

I like this but it would then be inconsistent with our own markdown config which uses drafts: true to build draft files as pages.

I guess we could also rename the markdown flag in the future although markdown.includeDrafts is a less obvious home run in terms of naming.

[bholmesdev]

Fair enough! I personally didn't make the connection between the markdown config and the RSS config, so the different naming didn't bother me. I'm okay keeping it as drafts if it makes documentation easier.

[bholmesdev]

Left a nit on naming, but I'm happy with this PR's final draft!

To be a good semver samaritan, I'd stick with a major for this one. We could switch the default of includeDrafts to true if we want to merge as a patch. Still, we'd probably flip back to false soon after for a major release, so that doesn't seem appealing to me.

[bholmesdev]

So maybe not the best time to hardcode a filter at all, but rather include steps in docs? 🙂

@fflaten Great point on Content Collections! I think the RSS integration will see some changes as content collections are more widely adopted. A loose set of ideas:

• Remove the import.meta.glob auto-resolver
• Introduce an rssSchema people can apply to their existing content config. This allows rich error messages on which properties are required by RSS, instead of the opaque "random entry broke RSS" error you see today:

import { rssSchema } from '@astrojs/rss';

const blog = defineCollection({
  schema: {
    ...rssSchema,
    /* other properties you may want */
  }
});

Excited to work on this more with the community!

[tony-sull]

This looks great! One quick note on the semver question - this should either be a major (if drafts are filtered out by default) or a minor (if drafts are included by default)

The second option is backwards compatible, but since it's really a new feature instead of a bug fix it's better to avoid using a patch release for it 👍

[sarah11918]

Approving the README on behalf of Astro Docs Maintainers! 🥳