fix(astro): preserve server/ directory structure for SSR Cloud Functions deploy#10537
fix(astro): preserve server/ directory structure for SSR Cloud Functions deploy#10537huextrat wants to merge 1 commit into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Astro framework integration to support a nested directory structure for server-side build output. Specifically, it modifies the directory copying logic, updates the bootstrap script to import from the new server path, and adjusts the unit tests accordingly. The reviewer suggested enhancing error handling by checking for the existence of the source directory before copying and throwing a descriptive FirebaseError if it is missing, which aligns with the repository's style guide.
| const { outDir } = await getConfig(sourceDir); | ||
| const packageJson = await readJSON(join(sourceDir, "package.json")); | ||
| await copy(join(sourceDir, outDir, "server"), join(destDir)); | ||
| await copy(join(sourceDir, outDir, "server"), join(destDir, "server")); |
There was a problem hiding this comment.
While this change correctly addresses the directory structure issue, it assumes the server directory always exists in the build output. If the build fails to produce this directory or if the Astro configuration is non-standard, fs-extra.copy will throw a generic 'file not found' error. Consider adding a check for the existence of the source directory and throwing a more descriptive FirebaseError to improve the user experience.
…ns deploy Astro's node adapter resolves paths via import.meta.url at runtime, so the server/ path segment must be present. Previously the CLI copied dist/server/ contents flat into the functions root, breaking path resolution and causing 503s on every request. Fixes: withastro/astro#16806
huextrat
force-pushed
the
fix/astro-ssr-server-dir-structure
branch
from
ad86a20 to
959c73c
Compare
2 participants
Problem
Astro SSR sites deployed to Cloud Functions via the
webframeworksexperiment return 503 on every request.Root cause:
ɵcodegenFunctionsDirectorycopies the contents ofdist/server/flat into the Cloud Functions root, losing theserver/path segment. At runtime, Astro's node adapter resolves asset paths relative toimport.meta.url, which becomesfile:///workspace/chunks/server_XYZ.mjs, noserver/segment, breaking resolution entirely.Discussed upstream in withastro/astro#16807
Fix
fixes:
@astrojs/nodemiddleware crashes on startup when deployed to Firebase (503) withastro/astro#16806Copy
dist/server/into<destDir>/server/instead of flat into<destDir>Update the bootstrap script to import from
./server/entry.mjsaccordingly