Require pollyfill is (sometimes) called with incorrect `dirname`

[timhaywood]

I'm getting some errors when running monaco built with bolt-cep, which I believe is related to the file paths not being correctly fixed with the /assets prefix.

The issues seems to be caused by the require pollyfill being bound with the incorrect basedir in some cases. Not sure if this is something that falls within vite-cep-plugin to fix, or if it will come up in other repos.

Current issue

Repo link

When serving the built files, requests are being made to js assets that don't exist:

These files exist, but as expected are located in /assets. Following the stack track shows that the error is thrown in the getSynchXHR() function as a part of the require() polyfill inlined to index.html.

Following the function calls upwards, we can see that require is being called bound the to the root dirname, but without the assets/ prefix.

This call can be seen in the source files, where require() is called:

require("./typescript.80793909.js");

Originally I thought this was an issue that could be fixed at the require() call site, but then I realized there are other times when require() is bound to the correct /assets dirname:

And adding /assets to the require call means that these executions result in the incorrect path `"assets/assets/...".

Cause

The dirname arg is bound here:

Logging dirname show's how sometimes it contains /assets while other times it doesn't.

dirname is bound to the result of loadPrerequisites(). Still investigating why this is different across calls, considering baseDir only seems to be set once — to the base URL without /assets.

Temporary fix

I was able to work around the issue by adding the following if statement to the require implementation to make sure asset paths are prefixed with /assets.

function require(dirname, file) {
  file = typeof file === "string" ? file.trim() : "";
  if (!dirname.includes("/assets/")) {
    dirname = dirname + "assets/";
  }
  // ....

Which fixes the issue, but obviously isn't much of a solution! Let me know if you've run across anything similar, or if I've missed anything. Will continue investigating and see if I can work up a good fix.