refactor: build pipeline

[ematipico]

Changes

This PR refactors the build process using the Pipeline class.

Here's a list of significant changes:

• created a new plugin-manifest plugin to generate the manifest. The manifest object is now emitted in a separate file called manifest.mjs. The file is emitted in the config.build.server folder. This is an internal refactoring. I went with this change because the manifest was repeated for each emitted entry/route, giving the impression that a manifest belongs to an entry/route. This isn't correct. A manifest belongs to the whole app. It made more sense to have a separate file with this information.
• created a new BuildPipeline class that extends Pipeline, which is responsible for giving all the essential information to its consumers; for example, BuildInternals and StaticOuputOptions are now inside BuildPipeline and with a series of getters, the consumers retrieve the information needed.
• changed how we retrieve the pages to render without using generators. Even though it wasn't necessary, now we reduced the number of loops.

Testing

Current tests should pass.

Docs

N/A internal refactor

[changeset-bot]

⚠️ No Changeset found

Latest commit: ce393bd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

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

[ematipico]

I thought we could store the encoding coming from a simple response using an internal header. What do you think? When generating a page, we read it and use it when we write the file to file system.

[natemoo-re]

I like it!

[ematipico]

80% of the code comes from plugin-ssr.ts.

[natemoo-re]

Looks great! Glad to see the manifest changes and a whole bunch of cleanup.

[natemoo-re]

I like it!

[bluwy]

Like the changes so far. Thanks for addressing my comments from the last PR!

Have some small nits below.

[bluwy]

Nit: we could type this as string[]

[bluwy]

nit: I think we can remove this import as BufferEncoding is a global with @types/node loaded.

[BlankParticle]

I think this check is the reason that so many hybrid render builds are failing,
in packages/src/core/build/plugins/plugin-manifest.ts:238 you are setting entryModules[BEFORE_HYDRATION_SCRIPT_ID] = '', then here you are checking if (typeof hashedFilePath !== 'string') and inside that check you are checking if (specifier === BEFORE_HYDRATION_SCRIPT_ID), but as you have already set the BEFORE_HYDRATION_SCRIPT_ID in plugin-manifest.ts so this check is never called.

as a result, while resolving BEFORE_HYDRATION_SCRIPT_ID in packages/astro/src/runtime/server/hydration.ts:157 we get "/" instead of "", for which this check passes and before-hydration-url is generated.

if (beforeHydrationUrl.length) {
		island.props['before-hydration-url'] = beforeHydrationUrl;
	}

So the potential fixes could be to change the function to be

async resolve(specifier: string) {
					//const hashedFilePath = manifest.entryModules[specifier];
        // EDIT: This one seems to work, all tests also passes
        const hashedFilePath = internals.entrySpecifierToBundleMap.get(specifier);
					if (typeof hashedFilePath !== 'string') {
					// If no "astro:scripts/before-hydration.js" script exists in the build,
					// then we can assume that no before-hydration scripts are needed.
					if (specifier === BEFORE_HYDRATION_SCRIPT_ID && hashedFilePath === "") {
						return '';
					}
						throw new Error(`Cannot find the built path for ${specifier}`);
					}
					return createAssetLink(hashedFilePath, manifest.base, manifest.assetsPrefix);
				},

or change the check at packages/astro/src/runtime/server/hydration.ts:157 to be

// Its more of a workaround than a fix
if (beforeHydrationUrl.length !== 0 && beforeHydrationUrl !== "/") {
		island.props['before-hydration-url'] = beforeHydrationUrl;
	}

I am down to make a PR to fix the issue (#8379 and many more), just waiting for confrimations from the maintainers