Option to place nested index.html entry point at the root of the output directory

[aweebit]

{
  build: {
    outDir: 'dist/client',
    rollupOptions: {
      input: 'client/index.html',
    },
  },
}

This setup puts the index.html file into dist/client/client instead of dist/client so that in the output directory, the file's placement relative to the project's root is mimicked. Now, when running the dev server, index.html is only served at /client/, and not at / as I would expect.

By contrast, with the following setup, the bundled copy of the .js entry point is placed at the root of the output directory (dist/server) as expected:

{
  build: {
    ssr: true,
    outDir: 'dist/server',
    rollupOptions: {
      input: 'server/src/index.js',
    },
  },
}

Here is a small demonstration: https://stackblitz.com/edit/vite-index-html-in-subdir

An obvious solution to the problem is to set root: 'client', but why should that be necessary?

It all probably works as intended, but having at least an option to place index.html at the root of the output directory would be very nice.

Related: https://stackoverflow.com/a/72326219/9861000

[aweebit]

@sapphi-red I could try to implement a solution and submit a PR if you tell me what your vision for the feature is. Should it be implemented as a build option like build.indexHtmlInRoot (or maybe build.hoistIndexHtml) so as not to be a breaking change?

Sorry about not using a template for this issue by the way, it was an accident.

[sapphi-red]

We avoid adding options that are possible to achieve with other options. https://github.com/vitejs/vite/blob/main/CONTRIBUTING.md#think-before-adding-yet-another-option
If it has general upside of introducing it, we consider adding an option. But your current proposal sounds too specific to your case to add.

[aweebit]

@sapphi-red is there any use in having the original location of index.html mimicked in the output directory? Do you think anyone relies on this behavior? Maybe it could be changed in the next major version release

[sapphi-red]

I believe many people are doing so because it's the way written in the docs.
https://vite.dev/guide/build.html#multi-page-app

Introducing a breaking change also requires a reason. It may be useful for your case, but I'm not sure whether it is for others cases. If you organize the possible use cases and prove it is generally useful, then we can consider changing it. Without that, keeping the current behavior feels more beneficial to me.

[aweebit]

@sapphi-red oh I see, supporting multiple entry points is actually a good reason to have this behavior, and differentiating between cases would make everything unnecessarily complicated. root: 'client' it is then! Thanks 😊