refactor: pipeline lifetime

[lilnasy]

Changes

• A Pipeline lasted the entire duration of a server while being concerned with only the request.
• This resulted in unsafe mutations needing to be performed on the global Pipeline before serving a request.
• The concept of hooks had to be introduced to make per-request actions easier.
• This PR repositions RenderContext as the hub of rendering by bringing control over creating other downstream objects, and rendering to it.
• Data previously in Environment is rolled into Pipeline, which now also exposes functions to retrieve styles and scripts for RenderContext to use.
• RenderContext is now in a sturdier position to take on the complexity of shifting RouteData during the course of middleware chain execution.
• See the new render-context.ts

                                                                                 
                                                                                               -->-- SSRResult -->-- Astro Global
                                                                             Request          /
                           App --- AppPipeline ---                              |            /
                                                  \                             v           /
       vite-plugin-astro-server --- DevPipeline --->--- Base Pipeline --- RenderContext ----                          -->-- Middleware
                                                  /    (per process)        (per page)      \                        /
                AstroBuilder --- BuildPipeline ---                                           \                      /
                                                                                              \                    /
                                                                                               -->-- APIContext -->-- Endpoint

(proposed)

• Each commit can be reviewed individually and passes all tests.

Testing

• Adjusted unit tests. Existing tests should pass.

Future

• routeData.type could go away. Differences between endpoint, pages, redirects, and fallbacks could be handled by the compiled page chunks themselves. It would be easy to create a standard ssrEntry format that exports a RenderContext -> Response function.
• It would greatly reduce the minimum server bundle size, because renderPage would not have to be included if all pages are prerendered and only ssrEntrys for endpoints remain.
• This PR defers gathering scripts, styles, links, propagation metadata to the "last" next(), giving the middleware chain the opportunity to change routeData, and "reroute" the request.

[changeset-bot]

🦋 Changeset detected

Latest commit: a6cf337

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

[ematipico]

Suggested change

	* The environment represents the static parts of rendering that do not change between requests.
	* The environment represents the static parts of rendering that do not change among requests.

[lilnasy]

The original seems correct.

[ematipico]

Docs missing

[lilnasy]

This is not new code. It is brought in from https://github.com/withastro/astro/blob/astro@4.3.5/packages/astro/src/vite-plugin-astro-server/index.ts#L7. I don't have the context to document it.

[ematipico]

I suppose the docs are outdated now, because it seems that this function doesn't throw any error anymore? We should update it

[lilnasy]

Do you know when that behavior changed?

[lilnasy]

I can address the code style comments at the end of the review cycle. Do you have any comments on the overall direction.

To summarise, half of Pipeline's concerns are being rolled into Environment and the other half into RenderContext.

[ematipico]

I can address the code style comments at the end of the review cycle. Do you have any comments on the overall direction.

To summarise, half of Pipeline's concerns are being rolled into Environment and the other half into RenderContext.

The direction seems reasonable to me; I have some thoughts:

• now that we "lifted up" most of the things from the pipeline inside the environment, I think "environment" can be called pipeline, because that was the original idea I had envisioned. Maybe all the "static" things that should change can be put inside a static object
• the createPipeline method, which returns a Pipeline doesn't have a clear meaning anymore. Maybe we can rename it RoutetRender, because that's what it does.
• RouteCache should be something that only the dev enviroment/pipeline should have, they should not be part of the base enviroment/pipeline
• The HiddenPipeline seems very cryptic, even when reading the code, documentation and its usage, it's very difficult to understand what it does

[lilnasy]

I think "environment" can be called pipeline, because that was the original idea I had envisioned

That's a good idea. RenderContext would be a more appropriate name for what's currently called Pipeline in this PR. RenderContext is intended to be the focus of the next and final refactor. We can wait until that one to merge this, because renaming the constructs multiple times will be confusing.