Enhance server functionality to serve static files and add production start command#69
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e3e187dc14
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| filePath.includes(`${sep}assets${sep}`) | ||
| ? "public, max-age=31536000, immutable" |
There was a problem hiding this comment.
This marks every file under /assets/ as public, max-age=31536000, immutable, but this repo’s Vite output uses stable names like assets/app.js and assets/app.css (see vite.config.ts output naming). Because those filenames do not change per release, browsers can keep old bundles for up to a year, so users may continue running stale code after deployment unless they hard-refresh. Either fingerprint asset filenames or use a shorter/non-immutable cache policy for these files.
Useful? React with 👍 / 👎.
|
|
||
| const getStaticFilePath = (requestUrl) => { | ||
| const url = new URL(requestUrl, "http://localhost"); | ||
| const pathname = decodeURIComponent(url.pathname); |
There was a problem hiding this comment.
decodeURIComponent(url.pathname) can throw URIError on malformed percent-encoded paths (for example, /%E0%A4%A). Since this happens before the local try block in handleStaticRequest, it falls through to the outer server catch and returns a 500 server_error instead of a client error, which is both incorrect behavior and easy for scanners to trigger repeatedly. Treat decode failures as a 400/404 in getStaticFilePath.
Useful? React with 👍 / 👎.
1 participant
This pull request introduces a production-ready server setup that allows the built game, Storybook showcase, and high-score API to be served together from a single DigitalOcean web service. The main changes focus on adding static file serving to the existing API server, updating documentation, and incrementing the package version.
Production server enhancements:
npm startscript topackage.jsonthat runs the unified production server (server/high-score-server.mjs).dist/directory, including game assets and Storybook, alongside the/api/high-scoresendpoint. Static routing supports clean URLs for main routes and assets. [1] [2] [3] [4]Documentation updates:
README.mdwith instructions for deploying the unified server on DigitalOcean, clarifying that both the game and API are now served from the same process.WHATSNEW.mddescribing the new production server capability.Other changes:
22.13.0to reflect the new features.