feat: base without trailing slash

[BenediktAllendorf]

Description

Allows setting a base without trailing slash. Closes #9236. Closes #8770. Closes #8772

I assumed, that base = "/foo/" and base = "/foo" should work equally for all sub-urls and only differ in the behavior when calling only the base (e.g., "localhost/foo" vs "localhost/foo/"). This means, that even without the trailing slash, all generated paths look like localhost/foo/css/... and not like localhost/foocss/....

Additional context

I used playground/assets for testing and reused that code (already available with /foo/ as base). There is already some duplicated code between relative-base and runtime-base, which probably could be combined altogether (?).

Not all tests are successful yet:

• pnpm run test-build assets leads to AssertionError: expected '/non-existent' to include '/foo/non-existent'. The problem is, that the path is not available and therefore, will be resolved at runtime - but this basically means, URL("non-existent", "/foo") will be called (instead of URL("non-existent", "/foo/") as it would do with a trailing-slash-base. I'm not sure, what the expected/desired behavior here would be?
• pnpm run test-serve assets
  • AssertionError: expected 'url("http://localhost:5173/foo/@fs/ho…' to include '/foo/nested/asset.png' and AssertionError: expected 'http://localhost:5173/foo/@fs/home/be…' to include '/foo/nested/asset.png' are both related to "@fs"-imports
  • AssertionError: expected 'url("http://localhost:5173/nested/ass…' to include '/foo/nested/asset.png' reveals a problem with inline-CSS.

For test-serve, I'm not sure where those problems occur (and why I don't see that neither with pnpm run dev nor pnpm run build/preview).

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

We have discussed this in the last team meeting and agree that /base should allow accessing from localhost:4173/base and /base/ would be localhost:4173/base/ like the current behaviour.

An implementation detail we want to make sure is that the ResolvedConfig should still append a / if /base (but no warning), to preserve compatibility with plugins that uses the base in ResolvedConfig. To differentiate between if the user specified a trailing / or not, we can have a separate internal property in ResolvedConfig to track it, as this information is only needed by the server.

[benmccann]

@BenediktAllendorf I finally figured out that most of the failing tests were not because of any code changes, but the test themselves. Once you put the test in a sub-directory they no longer pass. I changed the test setup to put the new tests alongside the old tests

[benmccann]

Hmm, the way I setup the tests seemed to cause them to collide with each other. I just removed them and instead edited the base path on the existing tests to not have a trailing slash. Since there are so many other tests that have a base path with trailing slash we should still have good coverage

[patak-dev]

Let's mark rawBase as internal. I would prefer to have this option as you did here, but there was a push in the last team meeting to go there only when there is a real use case out of the Vite core middleware.

[patak-dev]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
astro	✅ success
histoire	❌ failure
iles	❌ failure
ladle	✅ success
laravel	✅ success
marko	✅ success
nuxt-framework	❌ failure
rakkas	✅ success
svelte	❌ failure
vite-plugin-ssr	❌ failure
vite-setup-catalogue	✅ success
vitepress	✅ success
vitest	✅ success
windicss	✅ success

[patak-dev]

vite-ecosystem-ci looks the same as before this PR, except for Svelte @benmccann but I expect that you are aware or ok with this to move forward.

[benmccann]

Thanks for the review @patak-dev ! I marked the new field as internal. The svelte failure is unrelated and looks to be a network flake during CI setup, so I'm not worried about that one

[rssfrncs]

Hi is this released?

[patak-dev]

@rssfrncs yes, in Vite v4+