Should we use import.meta.url to load .data packages when enabling ESM?

[Guyutongxue]

When enabling -sEXPORT_ES6, we load .wasm relatively to .js automatically by using import.meta.url (if Module.locateFile not provided):

emscripten/src/preamble.js

Line 626 in ce5114b

wasmBinaryFile = new URL('{{{ WASM_BINARY_FILE }}}', import.meta.url).href;

But when loading .data files, the generated code just examines Module.locateFile, or else the raw file name is used:

emscripten/tools/file_packager.py

Line 770 in ce5114b

var REMOTE_PACKAGE_NAME = Module['locateFile'] ? Module['locateFile'](REMOTE_PACKAGE_BASE, '') : REMOTE_PACKAGE_BASE;\n''' % (js_manipulation.escape_for_js_string(data_target), js_manipulation.escape_for_js_string(remote_package_name))

This is some kind of inconsistence... would it better to make loadPackage support import.meta.url?

[sbc100]

Sounds reasonable. I guess that woulds mean some kind of new --es6-module setting for the file packager.

Can I ask, is there some reason why you don't use --embed-file though?

[Guyutongxue]

Can I ask, is there some reason why you don't use --embed-file though?

Well I was building clang (clangd exactly) to wasm and it needs a complete sysroot (nearly 20MiB I guess) to run. And the wasm file itself is ~50MiB. So I think using preload maybe better than embed... just don't make a single file too big to fetch.

[sbc100]

I see. Perhaps that makes sense. Remember though that embedding is more efficient as there is no copying needed. With --preload-file you have to copy all of the data from the downloaded file into the linear memory. So you might want to measure to see which is faster.