refactor: emit pages as physical entry points

[ematipico]

Changes

This PR is another internal refactor of our internal bundling strategy.

Before, the pages were bundled in a single entry point. This entry point was called entry.mjs.

With this refactor, now each page becomes an entry point.

For SSG builds, this should result in no changes whatsoever in its business logic. The build should work as it was, and the emitted files should still work as they were. The only effective change is that Astro needs to load each entry point when generating the build.

For SSR builds, this should result in an internal change. Before, all the pages were bundled inside the entry.mjs file. The pages are NOT included in the final bundle, but they are loaded via dynamic import. This is an internal change of the business logic, and the SSR build still needs to work.

Testing

The current tests MUST all pass.

Docs

I created a file inside the build/plugins/ folder. I noticed that there's some knowledge that I don't want to lose, and explaining it inside the code can be very tedious.

Unfortunately, I don't know ALL plugins, so consider this file as a starting point and a WIP. In fact, the plugin-ssr does more than I described, so probably someone else will chime in and write down something more.

cc @withastro/maintainers-docs for feedback, but I am not really sure if we need your review for internal knowledge, I don't want to give you more work than you already have! 😅

[changeset-bot]

🦋 Changeset detected

Latest commit: aa4959d

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

[bluwy]

With the plugin-middleware refactor, this condition wont pass anymore. It'll still pass if you have a src/middleware.ts because the else condition here catches it. But if I have src/middleware/index.ts, it won't output middleware.mjs anymore (index.mjs instead) (tested in middleware example). Maybe it's simpler to keep the plugin-middleware changes to handle this for now.

[ematipico]

Good catch! Completely missed that

[bluwy]

@ematipico I might've pointed the wrong thing, but with the new commit, this scenario still happens:

But if I have src/middleware/index.ts, it won't output middleware.mjs anymore (index.mjs instead) (tested in middleware example).

In the middleware example with src/middleware/index.ts, the middleware is output as dist/server/index.mjs, which I don't think is intentional, and we want dist/server/middlewares.mjs instead?

I was suggesting keeping the previous plugin-middleware code, or maybe there's a property in chunkInfo that we can use to identify is a middleware?

[bluwy]

Maybe:

if (chunkInfo.facadeModuleId?.includes('middleware') && chunkInfo.exports.includes('onRequest')) {
  return 'middleware.mjs'
}

A bit fragile though.

[ematipico]

Updated the code!

[bluwy]

Looks great! Thanks for refactoring and documenting this section of the codebase.