Stabilizing experimental.renderBuiltUrl

[patak-dev]

renderBuiltUrl

• Added in [email protected]
• Rationale in Original PR
• Docs
• Used by Nuxt, Marko, Astro, vite-plugin-vue (Code Search).

Open question: Should we move it from experimental to a vite-specific hook or to a config option in build.

We're looking to stabilize this feature in Vite 5. If you have feedback about it, let's use this discussion to gather it.

[xuzaixian]

When I only change renderBuildUrl function, the chunk hash will not change.
But chunk code is diffrent than before. Is it expected?
I have a demo here.
https://stackblitz.com/edit/vitejs-vite-mtwhq8?file=vite.config.ts

[patak-dev]

Good point, this may prevent us from stabilizing the feature. Would you create an issue with this reproduction so we can properly track it? Bringing a comment I did at #13973 (comment): The way we handle preloads may also get in the way to stabilize renderBuiltUrl. I don't know how to properly fix that one though if we need to wait until generateBundle. We could try to add something to augmentChunkHash, using dynamicImports to precalculate all the URLs we'll need to inject in the marker.

[xuzaixian]

Ok.
I created an issue. #13996

[victordidenko]

I'm not sure should I write here of I missed something...

In my specific case hashing bundle files is not enough to eliminate caching issues. I wanted to add extra query parameter for each .js file, requested from browser.

I tried this:

  experimental: {
    renderBuiltUrl(filename: string, { type }: { type: 'public' | 'asset' }) {
      if (type === 'asset' && extname(filename) === '.js') {
        return '/' + filename + '?TEST'
      }
    },
  },

But this doesn't seem to work for dynamic imports at all, here is part of my application router:

↑ all paths don't have required query parameter, and I don't know how to add it here.

Query parameter is added for preload though, so if I enable preload, same files loaded twice, with (preload) and without (dynamic import) query parameter...

[victordidenko]

You can see same behaviour by the link in the comment above:

It changes preload paths, but not the actual import path.

[victordidenko]

Regular imports are not affected as well...

Maybe I am using wrong API for my task 🤔

[victordidenko]

I've wrote this plugin:

    {
      name: 'add-query-parameter-plugin',
      generateBundle(_options, bundle) {
        for (const [filename, chunk] of Object.entries(bundle)) {
          if (extname(filename) === '.js' && 'code' in chunk && chunk.code) {
            // replace regular imports
            chunk.code = chunk.code.replace(
              /(from\s*['"][^"')]+\.js)(['"])/g,
              (_, $1, $2) => `${$1}?HELL${$2}`
            )

            // replace dynamic imports and regular imports without 'from'
            chunk.code = chunk.code.replace(
              /(import\(?['"][^"')]+\.js)(['"]\)?)/g,
              (_, $1, $2) => `${$1}?YEAH${$2}`
            )
          }
        }
      },
    },

But I don't like it, I really hate to mangle with source code using regular expressions ._. I am afraid this could shoot me in the foot.

[RebeccaStevens]

Not sure if this belongs here as it's related more to build.modulePreload.

But I had this idea the other day about whether it would be possible to use import assertions to specify if an import should be preloaded.

For example:

const data = await import("./foo", { with: { preload: true } });

A limitation would be that the import options would have to be statically defined so that the code can be statically analyzed at compile time.

[GMillerand]

I have the same issue as victordidenko. Here is the basic setup I've put in place:

    base: "client/dist/platform"
    experimental: {
        renderBuiltUrl(filename: string, { hostType }: { hostType: "js" | "css" | "html" }) {
            if (hostType === "js") {
                return { runtime: `window.buildUrl(${JSON.stringify(filename)})` };
            } else {
                return { relative: true };
            }
        }
    }

And in my index.html I have (for my test):

    ...
    <script>
      window.buildUrl = (filename) => {
        return `https://myCdnUrl/client/dist/platform/${filename}`
      }
    </script>
    ....

When I'm navigating into my app on https://myWebsiteUrl/myPage. I end up with all request duplicated only for js assets.
In the network tab I see for each chunk chunk-xxx.js a first request to https://myCdnUrl/client/dist/platform/chunk-xxx.js this request comes from a preload in the "main" chunk. After this request, I see another request to https://myWebsiteUrl/client/dist/platform/chunk-xxx.js, that comes from a simple import('./chunk-xxx.js') in another chunk file.
It looks like the importer is not able to identify or match the fact that the chunk is already imported.

I pushed a bit further in my testing, putting the same string in my buildUrl function i.e.:

    window.buildUrl = (filename) => {
        return `https://myWebsiteUrl/client/dist/platform/${filename}`
    }

In this case I don't see double loading of js assets and assets are all (or almost all) imported using the preload imports.

Do you have any idea of what can cause this duplication in js assets import.

[hdodov]

I want to give feedback that this feature is excellent for fixing asset paths when developing browser extensions. More context in crxjs/chrome-extension-tools#842 (comment).

[F5F5]

I have a mutiple entry app， and i want build app only once，but i cant get the assets's entry in this config😭

[skovhus]

Just tried this. Works really well to enable runtime injection of assets path – we use it to build feature preview support where assets might be stored in a different bucket.

[guillenotfound]

Just what I needed, in our case we use a base url pointing to our CDN, so doing return {relative: true} just works. I'm only doing it for JS files and I guess it should be enough? Or should I do it for other fileTypes too? 🤔