Open gweesin opened 2 months ago
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
.
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?
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?
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.
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.
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.
Description
The Webpack manifest supports a publicPath setting like
publicPath: '-/static'
, which allows third-party sites to directly load the application assets by referencing the manifest. For instance, Verdaccio requires custom assets to start with -/static, however, the Vite manifest might not include this specific prefix information.Suggested solution
Add a field in the
ManifestChunk
interface to denote the information, or incorporate the base configuration with a file field.Alternative
No response
Additional context
webpack configuration example:
webpack manifest example:
Validations