base config should work on manifest

[gweesin]

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:

module.exports = {
  // ...
  output: {
    path: `${env.APP_ROOT}/static/`,
    filename: '[name].[fullhash].js',
    publicPath: '-/static/',
  },
  plugins: [
    new WebpackManifestPlugin({
      removeKeyHash: true,
    })
  ]
  // ...
}

webpack manifest example:

{
  "main.js": "/-/static/main.6126058572f989c948b1.js",
  "main.css": "/-/static/main.6f2f2cccce0c813b509f.css",
  "favicon.ico": "/-/static/favicon.ico",
  "git.png": "/-/static/728ff5a8e44d74cd0f2359ef0a9ec88a.png",
  "logo.svg": "/-/static/93df1ce974e744e7d98f5d842da74ba0.svg",
  "pnpm.svg": "/-/static/81ca2d852b9bc86713fe993bf5c7104c.svg",
  "yarn.svg": "/-/static/1f07aa4bad48cd09088966736d1ed121.svg",
  "logo-black-and-white.svg": "/-/static/983328eca26f265748c004651ca0e6c8.svg",
  "npm.svg": "/-/static/737531cc93ceb77b82b1c2e074a2557a.svg",
  "index.html": "/-/static/index.html",
  "package.svg": "/-/static/4743f1431b042843890a8644e89bb852.svg"
}

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sapphi-red]

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.

[gweesin]

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?

[sapphi-red]

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?

[gweesin]

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.

[sapphi-red]

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.

[sapphi-red]

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.