feat: modern server static should always use system fs #6924
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: dd0c0c0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 286 packages
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 |
✅ Deploy Preview for modernjs-byted ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
caohuilin
approved these changes
Mar 11, 2025
yimingjfe
approved these changes
Mar 11, 2025
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Currently, there is inconsistency between the behavior in development and production environments. There are two middleware for hosting static resources:
static/,upload/, and other specific directories. And this middleware will use bundler's outputFileSystem instead real file system in dev mode.In development, the request process by these two middlewares. But in production, only process by Modern.js staticMiddleware.
This design will lead to many strange issues:
The
dist/a.jsonfile, process by bundler. It can be accessed in development, but can't be accessed in production.The
dist/static/a.jsonfile, not process by bundler. It can't be accessed in development, but can be accessed in production.The Modern.js staticMiddleware do nothing in development, becasue it always use bundler's outputFileSystem, so the file can't be find in rsbuild devMiddleware also can't be find in Modern.js staticMiddleware.
Therefore, we need to clarify this part of the logic and explain why we are doing it this way.
First, Modern.js staticMiddleware should only host resources from specified directories, and we should not expose server code to the outside.
Based on this, we need to ensure that user behavior remains as consistent as possible between the development and production stages.
Because during the development, rsbuild devMiddleware always hosts all bundlers, but Modern.js staticMiddleware cannot determine which files need to be hosted in the production environment (perhaps we could record bundler outputs, but this is not secure). However, due to security principles, Modern.js staticMiddleware cannot host the entire output directory.
Therefore, we ultimately considered this approach:
During the development phase, both middleware work, but staticMiddleware no longer uses the bundler's outputFileSystem, instead using the system's fileSystem. This ensures that files in the
static/directory that are not generated by the bundler behave consistently between development and production environments.The file not in
static/orupload/dir should never be hold by statciMiddleware. For example,jsPath,cssPath,favicon.ico, etc.. But due to historical reasons, we have retained them in this major version.Files generated by the bundler during the development that can be accessed through rsbuild devMiddleware but are not in the
static/directory will still be inaccessible through staticMiddleware in the production environment. We expect users to handle these files themselves, such as moving them to deployment artifacts as needed when deploying to Netlify, or uploading them to a CDN at some stage.The above is the discussion regarding static resource handling. Next.js has similar behavior, but it might be even stricter.
In this PR, we have replaced the fileSystem of staticMiddleware with the system's fileSystem. In the following PRs, we will gradually implement the changes according to the behavior described above.
dev.assetPrefixfor staticMiddleware.目前，开发环境和生产环境的行为存在不一致。有两个用于托管静态资源的中间件：
static/、upload/和其他特定目录中的资源。在开发模式下，该中间件会使用 bundler 的 outputFileSystem 而不是真实的文件系统。在开发环境中，请求会经过这两个中间件处理。但在生产环境中，只会经过 Modern.js staticMiddleware 处理。
这种设计会导致许多奇怪的问题：
dist/a.json文件，由 bundler 处理。在开发环境中可以访问，但在生产环境中无法访问。dist/static/a.json文件，未经 bundler 处理。在开发环境中无法访问，但在生产环境中可以访问。因此，我们需要明确这部分逻辑，并解释为什么这样做。
首先，Modern.js staticMiddleware 应该只托管指定目录中的资源，我们不应该将服务器代码暴露给外部。
基于这一点，我们需要确保用户行为在开发和生产阶段尽可能保持一致。
在开发过程中，rsbuild devMiddleware 总是托管所有 bundler 处理的资源，但 Modern.js staticMiddleware 无法确定生产环境中需要托管哪些文件非
static/目录下的文件（也许我们可以记录 bundler 的输出，但这并不安全）。而因为安全性原则，Modenr.js staticMiddleware 又不能托管整个产物目录。因此，我们最终考虑了以下方法：
static/目录下并且不是由 bundler 生成的文件在开发和生产环境中的行为一致。static/或upload/目录下的文件永远不应该由 staticMiddleware 托管。例如jsPath、cssPath、favicon.ico等。但由于历史原因，我们在这个大版本中保留了它们。static/目录下的文件，在开发阶段可以通过 rsbuild devMiddleware 访问，但在生产环境中仍然无法通过 staticMiddleware 访问。我们期望用户自己处理这些文件，例如在部署到 Netlify 时按需将文件移动到部署产物中，或在某个阶段将它们上传到 CDN。以上就是关于静态资源处理的讨论。Next.js 有类似的行为，但可能更加严格。
在这个 PR 中，我们已经将 staticMiddleware 的 fileSystem 替换为系统的 fileSystem。在接下来的 PR 中，我们将逐步按照上述行为进行改动。
dev.assetPrefix配置。dist文件移动到生产部署目录。Related Links
Checklist
pnpm run change.