__vitePreload dependencies could be relative to import.meta.url

[Rich-Harris]

Describe the bug

__vitePreload includes assumptions about where assets are being served from. In a normal Vite project those assumptions hold true, but in more bespoke situations they may not.

Additionally, in the case where CSS dependencies fail to load (whether due to a network failure, or because of the situation described above) the promise returned from __vitePreload will never resolve.

Reproduction

https://github.com/Rich-Harris/vite-preload-repro

Given sources like this...

// src/index.js
import('./foo.js').then((foo) => {
  foo.hello();
});

// src/foo.js
import './foo.css';

export function hello() {
  document.body.innerHTML = `<h1>Hello!</h1>`;
}

// src/foo.css
h1 {
  color: red;
}

...and a config like this...

const config = {
  build: {
    cssCodeSplit: true,
    lib: {
      entry: resolve('src/index.js'),
      name: 'app', // this doesn't seem to do anything?
      formats: ['es']
    },
    outDir: 'dist',
    minify: false,
    rollupOptions: {
      output: {
        entryFileNames: '[name]-[hash].js',
        chunkFileNames: '[name]-[hash].js',
        assetFileNames: '[name]-[hash][extname]'
      }
    }
  }
};

...the resulting dist/index-ed8ec7ff.js file contains this line:

__vitePreload(() => import("./foo-5368ca0f.js"), true ? ["/foo-5368ca0f.js","/foo-0a0d0fb0.css"] : void 0).then((foo) => {

In the case where assets are served from somewhere other than / (for example, on an external CDN), the /foo-5368ca0f.js and /foo-0a0d0fb0.css paths are meaningless. If they were relative paths instead, the implementation of __vitePreload could add the following...

  return Promise.all(deps.map((dep) => {
+   dep = new URL(dep, import.meta.url).href;
    if (dep in seen)
      return;

...and the resulting files would be more portable.

Meanwhile, to prevent the promise from hanging:

    if (isCss) {
-     return new Promise((res) => {
-       link.addEventListener("load", res);
+     return new Promise((res, rej) => {
+       link.addEventListener("load", res);
+       link.addEventListener("error", rej);
      });
    }

System Info

• vite version: 2.0.0-beta.69
• Operating System: Mac OS
• Node version: 12.18.3
• Package manager (npm/yarn/pnpm) and version: npm 6.14.6

[yyx990803]

It does take the base option into account - or do you intend to deploy it at unknown base locations?

[yyx990803]

Oh it looks like you are using Vite to build a lib with custom output filenames... yeah the current preload does assume an app with a known base location and can be improved.

[Rich-Harris]

Actually, in my case base should suffice — thanks, I looked for an option like that but didn't realise that was what I wanted. It's definitely possible to imagine a situation where the base path is unknown at build time, but it's perhaps less likely.

Rejecting the promise if the link errors might be worth doing independently of that anyway — would a PR be useful?

[jonaskuske]

definitely possible to imagine a situation where the base path is unknown at build time

Came across that situation yesterday! (wanted the app to work from /wp-content/themes/{someDirectory} and ideally also from /)

Setting base to "" (relative) and then using a <base> tag works! ¹

¹ unless you depend on the dynamic import polyfill because this upstream PR to resolve from document.baseURI instead of location.href was never merged

[yyx990803]

Rejecting the promise if the link errors might be worth doing independently of that anyway — would a PR be useful?

Absolutely!

[olemarius]

I have the same issue. We build locally where it will find the files using relative path, but in production the files are located on a cdn while website on a different webserver, so we're getting a bunch of 404's in the network traffic, before the same files are loaded using the base url.

So the current behavior still loads the files, but the expected behavior would be to point the preload to the cdn, respecting the base url.

[kayakyakr]

Another use case that this breaks is when trying to launch a sveltekit app from a chrome extension. This is a big deal in a content script, especially, where it's trying to preload those links via the embedded page's url.

I'm actually skipping the generated page to run the start script directly, but the module preload still throws a bunch of errors, and all of the css fails to load.

I'm still working out exactly what needs to happen and if there's a workaround, but this is pretty much putting the kibosh on my dreams of running sveltekit from an extension.

[kayakyakr]

I found a workaround presuming I have a stable chrome extension ID: I can provide chrome-extension://1234 as the asset base. Unfortunately, vite works against me here because of this method:

vite/packages/vite/src/node/utils.ts

Lines 103 to 104 in 82dc588

	export const externalRE = /^(https?:)?\/\//
	export const isExternalUrl = (url: string): boolean => externalRE.test(url)

where chrome-extension is not a valid external URL. Would appreciate a fix for that aspect, at least.