base config should work on manifest about vite HOT 6 OPEN

Vite's manifest only contains mappings of input entry files and output files.
Why does the base need to be included in manifest? I suppose you can calculate the URL with '/-/static/' + manifest[entry].file.

from vite.

Vite's manifest only contains mappings of input entry files and output files. Why does the base need to be included in manifest? I suppose you can calculate the URL with '/-/static/' + manifest[entry].file.

But in this case, the third party may not know what prefix to start with when reading the manifest.
This should be a black box, where third parties only need to know that resources can be obtained based on the manifest, right?

from vite.

the third party may not know what prefix to start with when reading the manifest.

Are you talking about an application different from Verdaccio? I thought the server knows the prefix in your use case.

This should be a black box, where third parties only need to know that resources can be obtained based on the manifest

Won't the server need to know the prefix itself rather than the URL for each assets to determine what path the bundle should be served?

from vite.

I'm discussing Verdaccio. I want to create a pull request for Verdaccio to support loading custom plugins built with Vite. I believe hardcoding '-/static' is not an elegant solution.

from vite.

So changing the manifest to be like the following example won't solve the problem as it'd require the user to configure the base path on Verdaccio side. (If requiring that is fine, then there's no need to add this feature.)

{
  "main.js": {
    "file": "assets/main.4889e940.js",
    "src": "main.js",
    "url": "/custom-base/assets/main.4889e940.js"
  }
}

To solve that, we'd need to add a base field. But given that the manifest contains the file mapping in the top level, we'd need to wrap that with an object to put the new base field.

{
  "base": "/custom-base/",
  "files": {
    "main.js": {
      "file": "assets/main.4889e940.js",
      "src": "main.js"
    }
  }
}

But this is a breaking change. We can avoid wrapping it with an object by putting a special object like below.

{
  "main.js": {
    "file": "assets/main.4889e940.js",
    "src": "main.js"
  },
  "__metadata": {
    "base": "/custom-base/"
  }
}

But this is still a breaking change, because it is normal for the tools that read the manifest to expect all entries in the manifest are file mappings (e.g. the tool may expect all entry to have file field and that file to exist).
I guess we need a strong benefit to do this.

from vite.

Ah, we can add a new file that contains these kinds of metadata. But that would require a new option for configuring the output path like build.manifest. It's also possible to implement that by a plugin.

from vite.