docs: document Environment API breaking changes

[matthewp]

Description (required)

Updates the v6 guide with breaking changes from the Environment API refactor

Related issues & labels (optional)

For Astro version: 6.x. See astro PR #14306.

[netlify]

✅ Deploy Preview for astro-docs-2 ready!

Name	Link
🔨 Latest commit	68308eb
🔍 Latest deploy log	https://app.netlify.com/projects/astro-docs-2/deploys/692dff8cd4d1a00008633be4
😎 Deploy Preview	https://deploy-preview-12809--astro-docs-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[astrobot-houston]

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File	Note
en/guides/upgrade-to/v6.mdx	Source changed, localizations will be marked as outdated.

Warnings reference

Icon	Description
🔄️	The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

[ArmandPhilippot]

Thanks Matthew, this looks great. I left a few suggestions, mostly about headings/code snippet consistency.

My main concern is the "RouteData.generate() Removed" section. I don't think we document RouteData directly, but I can see it used in the Integrations page to transmit properties. Looking at the implementation PR, it seems generate() still exist under another format. So, maybe this is the change we want to document here? (but maybe I'm wrong, the implementation PR contains a lot of changes, I haven't checked all the details yet 😅 )

Also, while I was quickly looking at the implementation PR, I noticed we have two new properties for setAdapter(): we'll need to document them in the Adapter API guide under Building an adapter. We now have a subheading for each available prop, so we'll need to add devEntrypoint and entryType there.

[sarah11918]

Thanks for this @matthewp ! Letting you know that I'm working on this, because it's a lot of content especially at the beginning of the guide that probably only affects integration/adapter authors. I'm thinking we could handle it similar to our removing experimental flags: mention the changes and link to the item entry that shows up in its regular place below:

So my suggestion would be to address the Vite Environment API briefly, like a dependency (it kind of is, as a thing we're using) maybe something like:

Suggested change

	## Environment API Changes
	Astro v6.0 introduces significant changes to how Astro manages different runtime environments (client, server, and prerender) using Vite's new Environments API. Integration and adapter maintainers should pay special attention to these changes.
	### Vite Environment API
	<SourcePR number="14306" title="feat: integrate vite environments"/>
	Astro v6.0 introduces significant changes to how Astro manages different runtime environments (client, server, and prerender) after an internal refactor to use [Vite's new Environments API](https://vite.dev/guide/api-environment).
	Integration and adapter maintainers should pay special attention to changes affecting these parts of the Integration API and Adapter API:
	- [integration hooks and HMR access patterns](#changed-integration-hooks-and-hmr-access-patterns-integration-api)
	- [`SSRManifest` structure](#changed-ssrmanifest-interface-structure-adapter-api)
	- [generating routes with `RouteData`](#removed-routedatagenerate-integration-api)
	- [routes with percent-encoded percent signs (e.g. `%25`)](#removed-percent-encoding-in-routes)
	- [astro:ssr-manifest` virtual module](#removed-astrossrmanifest-virtual-module-integration-api)

And then that's it, short and sweet, and those 5 entries of things that were changed/removed etc. we would add to the lists below. Part of my thinking is yes, these changes were all made when implementing Vite's API, but as breaking changes, they aren't otherwise in their own "category", and people still need to see ALL the breaking adapter/integration API changes. So, this makes people aware that there was a big refactor and lots of changes to those APIs as a result, but doesn't make e.g. someone who just needs to know how to update their content collections navigate through/past all this.

So, I'm working on a version that then moves the content below into place, and traces each of those changes back to the rest of docs to the thing that they relate to to make sure that e.g. removed things are in fact removed from existing docs.

That means that @ArmandPhilippot and I might have some questions to verify regular docs content too as we go through this! (I already suspect that RouteData.generate needs some attention, because I already came across something in an earlier PR with @florian-lefebvre that our docs currentlysay RouteData was deprecated and to use the IntegrationsRouteData (which is a subset of the internal RouteData I believe?)

So be prepared for some questions as we work through this, but I think something like my suggestion above might be a good way to handle this!

[sarah11918]

I just added a commit to reorganize and start to put these in our format.

• These still need full editing and tracing through to docs to make sure all changes are reflected in regular v6 docs!
• I have left some code comments in items for further work