是否支持 new URL('xxx.wasm',import.meta.url) 方法，目前测试是无效

[chenli1989]

vite.config.ts 文件配置是以下：编译结果还是转为 base64 内联，是否支持wasm文件？还是哪里配置不正确？

libAssetsPlugin({
  include: ['**/*.wasm'， ‘**/*.svg’],
}),

代码是

// 无效
new URL('demo.wasm', import.meta.url) 

// 无效
new URL('demo.svg', import.meta.url)

编译结果还是 base64

// wasm
new URL('data:application/wasm;base64,xxxxxxx')

// svg
new URL("data:image/svg+xml,%3csvg%20width=xx')

[coder-layne]

之前没有遇到过 new URL 的情况，我需要了解下

[coder-layne]

@chenli1989 new URL('xxx.wasm', import.meta.url) 形式的资源引用是由 Vite 内置插件处理的，lib-assets 也可以采用相同的方式获取到被引入的资源，然后将 Vite 生成的 base64 内容替换回资源的地址，但我还需要对这种形式使用 URL 进行一些调研，避免破坏已有的代码。

[DenizUgur]

I would like to chime in here as well. I hope translation was correct and I didn't miss anything but using the following syntax is a good workaround:

instead of

new URL("./demo.wasm", import.meta.url).href

use

import demoURL from "./demo.wasm?url"

This solved the base64 encoding issue but I get the following warning(s) during build

No name was provided for external module "./assets/demo-991e9643.wasm" in "output.globals" – guessing "demoURL".

Not sure if this is something to worry about though. Any comments @coder-layne?

[coder-layne]

@DenizUgur I'm not quite sure what the difference is between URL and import in terms of usage scenarios, and I also welcome solving @chenli1989 's issues in this way if it fits his scenario.

This warning occurs because the plugin emits assets to a specified directory and then marks them as external. If your output is in umd format, you need to provide variable names to access these assets from the globalThis. If you want your package users to access these assets through addresses provided by you, you can offer a publicUrl option. Otherwise, you should provide umd or cjs format outputs.

[DenizUgur]

Thank you @coder-layne for your reply. I get these warnings for a es build though. What would happen in that case? Do I need to do anything specific?

[coder-layne]

@DenizUgur I am using the build configuration in the project playground, and I did not encounter the warning you mentioned when outputting the es format outputs. Can you provide a minimal reproducible version?

[DenizUgur]

It was difficult to reproduce but here you go: codesandbox link. Run nx build test-library after you open the devbox.

[coder-layne]

@DenizUgur The plugin will externalize files that meet the inclusion criteria, and Rollup will attempt to acquire the global variable names of external modules when outputting in the iife and umd formats. If this fails, a warning will be output. So, will this warning appear when the output format is set to es? This is because we used worker mode, where the default format is iife.

[coder-layne]

@DenizUgur Additionally, the plugin is used to handle asset files. It treats the content of files as strings, which may cause problems when dealing with scripts.

[DenizUgur]

So, will this warning appear when the output format is set to es?

No warnings, that was it. Thank you for pointing that out.

It treats the content of files as strings, which may cause problems when dealing with scripts.

I'm using the syntax I've mentioned above to get the asset's public URL so I'm not interested with the content as well.

[coder-layne]

@DenizUgur Glad that the plugin fits your scenario :)

[P422L]

@coder-layne Does the plugin work for this syntax?

new URL('demo.wasm', import.meta.url) 

In my case I'm not getting it to work by configuring the plugin and I don't have the option to change the syntax to the suggested format

import demoURL from "./demo.wasm?url"

because it's in an npn package I'm using and don't have control over.

[coder-layne]

@P422L Thank you for your feedback. It seems necessary to reconsider the initial plan.

@chenli1989 new URL('xxx.wasm', import.meta.url) 形式的资源引用是由 Vite 内置插件处理的，lib-assets 也可以采用相同的方式获取到被引入的资源，然后将 Vite 生成的 base64 内容替换回资源的地址，但我还需要对这种形式使用 URL 进行一些调研，避免破坏已有的代码。

[P422L]

It would be awesome having the plugin supporting those imports as they've become vites recommended way of dynamically importing.

[coder-layne]

@P422L Just released v1.1.0 under the next tag. Passed basic local tests—let me know if it fixes your issue :)