build fails starting with 4.11.6

[mattly]

Astro Info

Astro                    v4.12.2
Node                     v20.6.1
System                   macOS (arm64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             @astrojs/mdx
                         astro-robots-txt
                         @astrojs/sitemap
                         @astrojs/solid-js
                         astro-meta-tags

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

I have a site that was building with 4.11.5, and stopped building with 4.11.6. astro build exits with the following errors in "generating static routes"

Unable to find the module for src/pages/404.astro. This is unexpected and likely a bug in Astro, please report.
  Stack trace:
    at generatePage (file:///Users/mattly/projects/personal-site/lyonheart-broken-bare/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/astro/dist/core/build/generate.js:156:11)
    at async staticBuild (file:///Users/mattly/projects/personal-site/lyonheart-broken-bare/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/astro/dist/core/build/static-build.js:105:7)
    at async AstroBuilder.run (file:///Users/mattly/projects/personal-site/lyonheart-broken-bare/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/astro/dist/core/build/index.js:168:7)
    at async build (file:///Users/mattly/projects/personal-site/lyonheart-broken-bare/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/astro/dist/cli/build/index.js:20:3)
    at async cli (file:///Users/mattly/projects/personal-site/lyonheart-broken-bare/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/astro/dist/cli/index.js:168:5)

Removing the 404.astro file will cause the same error with the next alphabetically-sorted page file in src/pages, in my case about.mdx; and removing that will fall through to colophon.mdx, etc.

I created a support thread on discord, "dreyfus" kindly helped with diagnosis, suggested it might be related to this commit and asked I open an issue here.

What's the expected result?

I expect it to build as it does on 4.11.5

I am very unsure about what parts of my long-running site source are contributing to this problem, and have been unable to create an example from scratch. I copied my repository, stripped the assets I cannot make public, and cloned it to the example's initial commit.

In an effort to reduce the surface area for diagnosis, I removed much of the contents while preserving the parts that contribute to a build error and created a second commit. I would not expect the second commit to build cleanly as-is, but I would expect it to not have this "Unable to find the module for page" error, and I would expect the initial commit to build.

Link to Minimal Reproducible Example

https://github.com/mattly/lyonheart-bare-broken

Participation

• I am willing to submit a pull request for this issue.

[bluwy]

This is because dist/pages/404.astro.mjs looks like this:

import { _ as _page, __tla as __tla_0 } from '../chunks/404_D1p8AGKs.mjs';
let renderers, page;
let __tla = Promise.all([
    (()=>{
        try {
            return __tla_0;
        } catch  {}
    })()
]).then(async ()=>{
    page = ()=>_page;
});
export { renderers, page, __tla };

The __tla is caused by https://github.com/Menci/vite-plugin-top-level-await, it's incorrectly marking an await in an Astro code, particular this, as a top-level await, which is not. I've sent a fix upstream: Menci/vite-plugin-top-level-await#53

With that PR, the TLA transformation shouldn't happen and should fix the issue. When it did before, it'll cause page to be undefined for a short moment, causing Astro to assume that something's wrong, hence the error. Ideally, vite-plugin-top-level-await shouldn't be involved in the SSR build at all, but it's not easily possible I think to configure that in Astro.

Anyways, while #11387 did caused the issue, it only inadvertently revealed a bug from a different plugin, so I don't think this is a regression in Astro. Since there isn't anything else for Astro to fix here, I'll close the issue.