Asset handling should be end user firendly

[kaisalmen]

@CGNonofr I guess it makes sense to open an issue here to discuss possible ways forward.

Ideally, end-users of monaco-vscode-api will not notice that assets like wasm, mp3, etc are required to be handled/loaded.

If this cannot be achieved there should be a common way to override fetch instructions (e.g. a config function that allows to provide an object with fetch override instructions). If this is not used the default settings are used.

[CGNonofr]

Seems like a good idea! I don't really know how to implement it though

Don't you think it's as easy for the end user as configuring its bundler to do so?

[CGNonofr]

monaco-editor already expects the end user to load ttf files as URL I think so we're just introducing the same thing for mp3 and wasm

[kaisalmen]

Yes, I guess code transformation process needs to integrate "hook" code where resources are loaded from urls. And here you can use configured values.

For example (idea) if nothing is provided the defaults are used:

StandaloneServices.globalSettings({
  basePath: '..',
  onigWasmPath: './node_module/svscode-onigurum/release/',
  mp3Path: '../mps3s'
});

Questions are? Is this feasible? Are there already global settings available one could re-use/extend?

[CGNonofr]

I don't think the problem is about path (why would you change it?) the problem is about forcing the bundler to load the file as an url.

Some bundlers support it by configuration (vite supports the ?url query string, with webpack you can use the file-loader! prefix ; probably deprecated) but it's not standard.

Even if we provide a way to customize the loading, we'll still have an import of the wasm in the code and the bundler will still try to create a bundle for it, even if not used

One solution would be to transform the binaries into base64 and put them in js files, but it would increase the size by more than 30%.

I don't have any other idea

[kaisalmen]

Some bundlers support it by configuration (vite supports the ?url query string, with webpack you can use the file-loader! prefix ; probably deprecated) but it's not standard.

I currently don't know a way how to tell vite or webpack (monaco-languageclient) how to resolve the cors problem. Do you know a solution to this problem? Why is this problem not occur in the demo here?

I was wondering if the getWorker approach from monaco-editor could be a blueprint?

[CGNonofr]

I currently don't know a way how to tell vite or webpack (monaco-languageclient) how to resolve the cors problem

A cors problem? I'm not sure what you are talking about

I was wondering if the getWorker approach from monaco-editor could be a blueprint?

The problem with it is it requires the user to do something about it (install a webpack loader or add some code related to it)

[kaisalmen]

A cors problem? I'm not sure what you are talking about

I was referring to this problem: TypeFox/monaco-languageclient#470 (comment)

[CGNonofr]

Ok that's not a Cors issue at all. You got this error because by default vite return the file:// url when loading an asset in dev mode, it works when using it on <img> tags or other things but vscode does a fetch by hands on it and it fails. The solution is to add the server.origin in the vite config

[kaisalmen]

The solution is to add the server.origin in the vite config

Thank you. This works. How did you know this was actually the problem? I wasn't able to derive this from the error. Did you encounter this problem before? Oh, I just check the demo and saw that you set origin: 'http://localhost:5173'. I overlooked that one before.

[CGNonofr]

Thank you. This works. How did you know this was actually the problem?

I've dug into the code to implement the require.toUri stuff and I had the problem at first

[kaisalmen]

@CGNonofr I will close this now. If I stumble upon anything related in the future I will open specific issues/PRs.