💡 RFC: `date` and `future` for Markdown posts

[FredKSchott]

What is Missing from Astro Today?

• date as a top-level primitive for Markdown posts/files
• buildOptions.future as an option to ignore posts/files with date set to the future
• borrowed from: https://jekyllrb.com/docs/configuration/options/
• got feedback from a user that this was an essential feature from their blog setup

Proposed Solution

Implement this to match Jekyll.

Help Make it Happen!

• I am willing to submit a PR to implement this change.
• I am willing to submit a PR to implement this change, but would need some guidance.
• I am not willing to submit a PR to implement this change.

[jasikpark]

Maybe this is something that can be built into the documentation for how to filter the results of Astro.fetchContent based on those keys? Though I guess this would be more for the automatic markdown -> page translation...

[FredKSchott]

Good call out, we probably want both (top-level enable/disable for pages, and then enable/disable for each fetchContent() call.

[matthewp]

For the flags can we just have one --draft flag? Since a future date and a draft are very similar, I think it makes sense to combine the flags into one; I don't think there's a use-case to build the future posts but not the draft ones.

[natemoo-re]

RFC Discussion: @FredKSchott we're okay moving forward with this, but want to iron out the design a bit:

• date or publishDate or something else? Prior art for reference
• Can we surface posts that are (not) published in the CLI? Would love to see a design for this.
• What date format are we using? ISO_8601

[FredKSchott]

Hey everyone! Our current RFC process is beginning to break down at this size, with over 50 open RFCs currently in the "discussing" stage. A growing community is a great problem to have, but our ability to give you RFC feedback has suffered as a result. In an effort to improve our RFC process, we are making some changes to better organize things.

From now on, all RFCs will live in a standalone repo: https://github.com/withastro/rfcs

This allows us to do three things: 1) Use threaded discussions for high-level ideas and improvements, without necessarily requiring an implementation for every idea. 2) Improve the quality of our RFC template and the speed/quality of all feedback. 3) Support inline comments and explicit approvals on RFCs, via a new Pull Request review process.

We hope that this new process leads to better RFC weekly calls and faster feedback on your RFCs from maintainers. More detail can be found in the new RFC repo README.

---

We can't automatically convert this issue to an RFC in the new repo because new RFC template is more detailed that this one. But, you can still continue this discussion in the new repo by creating a new Discussion in the RFC repo and copy-and-pasting this post (and any relevant follow-up comments) into it. Discussions are available for high-level ideas and suggestions without the requirement of a full implementation proposal.

Then, when you are ready to propose (or re-propose) an implementation for feedback and approval, you can create a new RFC using the new RFC template. More detail about how to do this can be found in the new RFC repo README.

Thanks for your patience as we attempt to improve things for both authors and reviewers. If you have any questions, don't hesitate to reach out on Discord. https://astro.build/chat

[AleksandrHovhannisyan]

I'm considering migrating from Eleventy to Astro and this is something I was interested in, but I couldn't find the relevant issue or discussion for it in the roadmap repo linked above. Does anyone know if this was ever released? Based on my testing, it seems this is currently unsupported, but I see commit 4e3b3a7 references it (although I can't tell what the relevant change was).