Add a new compiler setting that tells the JS build output to expect that the locateFile module hook will be used

[dasa]

This is an enhancement request.

I think this setting would reduce unnecessary JS code and complexity in the output that's left unused when locateFile is defined on the Module.

Perhaps it could be called USE_LOCATE_FILE, and a runtime error would be expected if locateFile was not defined.

/cc @RReverser

[sbc100]

If there are code size saving that result then we should certainly do this.

Could you point the code that you think can be elided in this case?

[RReverser]

We already have that mechanism for arbitrary Module settings though, do we really need another named setting?

[dasa]

My thought was that

      function locateFile(path) {
        if (Module["locateFile"]) {
          return Module["locateFile"](path, scriptDirectory);
        }
        return scriptDirectory + path;
      }

Could be reduced to:

      function locateFile(path) {
        return Module["locateFile"](path, "");
      }

And then this code that sets up _scriptName and scriptDirectory could be removed, but maybe I'm missing something.

    var _scriptName = typeof document != "undefined" ? document.currentScript?.src : undefined;
    if (typeof __filename != "undefined") _scriptName ||= __filename;

// ...

        if (ENVIRONMENT_IS_WORKER) {
          scriptDirectory = self.location.href;
        } else if (typeof document != "undefined" && document.currentScript) {
          scriptDirectory = document.currentScript.src;
        }
        if (_scriptName) {
          scriptDirectory = _scriptName;
        }
        if (scriptDirectory.startsWith("blob:")) {
          scriptDirectory = "";
        } else {
          scriptDirectory = scriptDirectory.substr(0, scriptDirectory.replace(/[?#].*/, "").lastIndexOf("/") + 1);
        }

[sbc100]

Do you mean INCOMING_MODULE_JS_API? I think one issue is that inclusion in this list just tells emscripten "I may set this as an incoming argument".. and not "you can depend on this setting being set".

We could perhaps change this meaning for certain settings such as locateFile?

[sbc100]

BTW , if we really want to shave some serious code size we should be looking at the wasm or wasmBinary settings which could also allow is to avoid including all of the hundreds of lines of module loading code.. but -sMINIMAL_RUNTIME already does this. Have you looked into MINIMAL_RUNTIME by the way?

[sbc100]

@dasa, BTW can I ask what you are using locateFile for? Is it because you cannot host your wasm file alongside your js file?

[dasa]

Have you looked into MINIMAL_RUNTIME by the way?

I have not.

BTW can I ask what you are using locateFile for? Is it because you cannot host your wasm file alongside your js file?

Correct, for example, I have a NPM package that loads the Wasm file from a CDN.

[kripken]

Do you mean INCOMING_MODULE_JS_API? I think one issue is that inclusion in this list just tells emscripten "I may set this as an incoming argument".. and not "you can depend on this setting being set".

@sbc100 I think that is the same, unless I am missing your meaning? That is, the setting means "the user may set Module.X; if a setting is not in this list, the compiler can assume the user does not set Module.X".

In fact, locateFile is already in the default list:

emscripten/src/settings.js

Line 987 in 8cc1654

'loadSplitModule', 'locateFile', 'logReadFiles', 'mainScriptUrlOrBlob', 'mem',

So I agree with @RReverser that we may not need a new setting here, we can take advantage of the existing one, unless I'm missing something.

[dasa]

I'm proposing a setting telling the compiler that it can count on the user setting locateFile so it can remove unused code.

[dasa]

The values in INCOMING_MODULE_JS_API seem to be treated as things that MAY be set rather than MUST be set. Instead of a new setting just for locateFile, maybe a new setting for things that MUST be set would be more generic.

[sbc100]

I guess one option would be to add new setting such GUARANTEED_INCOMING_MODULE_JS_API (but with a better name).

Alternatively we could keep the existing setting and change its meaning for certain elements from "may have" to "will have"?

[sbc100]

Or perhaps as you suggest we create a specific new setting just for this?

I've always disliked the setting name INCOMING_MODULE_JS_API so maybe this is our chance to come up with a better name?

[sbc100]

Can we imagine a use case were a developer want to be able to supply locateFile ... but not all the time?

[RReverser]

Idk, it seems like such a tiny saving (a few bytes of the if, and it's not even a repetitive pattern) that I'd say a separate setting/handling just to save those is not worth it.

[dasa]

It's not much, but isn't it also the code that sets scriptDirectory?

[sbc100]

I believe the _scriptName code is still needed/used even if locateFile is specified. Specifically I think _scriptName is used in pthread builds when creating new workers, regardless of locateFile.

[kripken]

Ah, so this is to save code size in the case where it is provided, sorry for misunderstanding before.

I tend to agree with @RReverser that this may not be worth it. Optimizing code size for the default is worth doing - most people don't need locateFile - and I think when people use an optional setting like locateFile it's ok to add a little code size. Optimizing all such optional settings by adding new settings would be a lot of work.

With that said, if the code size difference was very large I'd be ok with a new setting, but in this case I think it's quite minor? I would also be ok with a generic new setting like GUARANTEED_INCOMING_MODULE_JS_API as @sbc100 proposed if we think it will have more uses.