Add prefix option to change output sitemap filenames

[ktym4a]

Description (required)

Add prefix to sitemap options so that the filename can be changed optionally.

For @astrojs/sitemap version: 3.1. See astro PR withastro/astro#9846

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	Feb 13, 2024 9:01pm

[at-the-vr]

Is this an upcoming feature? I tried to run this on a stackblitz instance and it didn't worked there 😕
edit: forgot to mention - I also updated using npx @astrojs/upgrade

[ktym4a]

Is this an upcoming feature? I tried to run this on a stackblitz instance and it didn't worked there 😕

Yes, it is.
It will be released in astro v4.4.

[at-the-vr]

I could not find it in their milestone 😕, can you pinpoint it ?

[ktym4a]

I have received this comment so I am assuming it will be released in v4.4.
withastro/astro#9846 (comment)

[sarah11918]

Ah, I see everyone's confusion! Because this is an integration minor, it doesn't release necessarily with Astro 4.4, but rather with the next version of @astrojs/sitemap! Integration packages release separately from core, and could be together but might not be!

I'll update the PR description!

[sarah11918]

This looks great @ktym4a ! Just left a suggestion for the intro text, but you did a great job copying the style and code format of the other config options. Thank you for making this so easy! 🙌

[sarah11918]

Looks great! We have added the label so that this gets merged when the new integration version is released, and not before. So nothing left for you to do! Thank you again for your contribution!

[kevinzunigacuellar]

!coauthor

[github-actions]

Co-authored-by: ktym4a <shoma@ktym4a.me>
Co-authored-by: Atharva <atharvapise19@gmail.com>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>

[ktym4a]

I share here that revert withastro/astro#9846.
details: withastro/astro#10179, withastro/astro#10171

[sarah11918]

Hi @ktym4a !

I've checked with our core platform team, and they think the best thing to do with the reverting of the other PR is to close this docs PR right now.

This PR can be reopened if we go with this solution in future! Or, if another solution is created, a new Docs PR can be created!

So, I will close this one right now, but I think we are in a good place to know how to document a similar solution if it's implemented! 🙌