feat: support server.base configuration

[9aoy]

Summary

Support modifying the base path of the server through server.base configuration.

By default, the base path of the server is /, and users can access output files such as index.html and public folder assets through http://localhost:3000/.

When we want to access these files through http://localhost:3000/foo/, we can configure the following:

export default {
  server: {
    base: '/foo',
  },
};

Related Links

#1242

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).

[netlify]

✅ Deploy Preview for rsbuild ready!

Name	Link
🔨 Latest commit	6d860e2
🔍 Latest deploy log	https://app.netlify.com/sites/rsbuild/deploys/66fca3381881ed0008d53c90
😎 Deploy Preview	https://deploy-preview-3542--rsbuild.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 74 (🟢 up 3 from production) Accessibility: 97 (no change from production) Best Practices: 100 (no change from production) SEO: 92 (no change from production) PWA: 60 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[nanianlisao]

not so sure about this setup, especially its link with output.assetPrefix. Looks like server and output should be split.

If it is just for processing publicDir, this also needs to affect copyOnBuild. Should you consider placing it in publicDir, such as publicDir.base?

[9aoy]

not so sure about this setup, especially its link with output.assetPrefix. Looks like server and output should be split.

Configuring server.base is usually because not all projects will be deployed to the root path. At this time, server.base can be configured as a subpath, which ensures that local development and preview are consistent with the online access path.

And server.base is just the default value of output.assetPrefix. If output.assetPrefix is ​​defined, output.assetPrefix's own configuration will be used.

If it is just for processing publicDir, this also needs to affect copyOnBuild. Should you consider placing it in publicDir, such as publicDir.base?

Not just for processing public Dir. You can read related discussions #1242

[nanianlisao]

Configuring server.base is usually because not all projects will be deployed to the root path.

I think this should be something output.assetPrefix controls, and when I have a problem I'll check it first, rather than some config I might be overlooking.

Judging from #1242, I think the core requirement is still that server.publicDir needs to support specifying additional directories when copying.

It's also worth mentioning that I don't like dev.assetPrefix either. Using process.env.NODE_ENV === 'production' ? '/cv3/' : '/' makes me less prone to making mistakes.

[chenjiahan]

It's also worth mentioning that I don't like dev.assetPrefix either. Using process.env.NODE_ENV === 'production' ? '/cv3/' : '/' makes me less prone to making mistakes.

I am neutral about dev.assetPrefix. We have considered remove it to reduce configuration options, but it will break early users and some ByteDance projects.

In most projects I've encountered, the assetPrefix used by dev and prod is usually different, users will use a CDN url as assetPrefix in the prod mode. So it still makes sense to provide a separate assetPrefix option for dev mode.

[chenjiahan]

Since base is a new option, I propose to make it stricter:

1. A base value should always end with a trailing slash: '/foo/'.
2. We do not need to remove the tailing slash in process.env.BASE_URL

[FugitiveLc]

I think this configuration is necessary because I also encountered this problem when migrating old projects