Cache-by-position or reinit each time

[Jack-Works]

Possible solution:

Add a unique (prior art symbol vs unique symbol in typescript) modifier to tell which the semantics should be use.

const x = [0,1].map(() => unique module {})
// two different module. Need opt-in cause performance trap
const y = [0,1].map(() => module {}) // the same module

[nicolo-ribaudo]

Since modules don't capture variables in the current scope, you can always hoist the module outside of the callback if you want an unique one.

[surma]

The question came up in the context of the follow code sample:

someButton.onclick = () => runInWorker(module { ... });

Currently, each execution creates a new module block, resulting in a new module being added to the module map in import(). The worry here is that this could be a performance foot gun, as the module map will grow each time the event handler is executed. The module map not well-understood by developers (they don’t come into contact with it) and they might not be aware of the long-term cost of a pattern like this.

If we cached module blocks by source position, executing the same module block would return the same module block. More specifically, that would mean:

const arr = [];
for(let i = 0; i < 10; i++) 
  arr[i] = module { /* ... */ }; 

await import(arr[0]) == await import(arr[1]);

While this mitigates potential the performance foot gun, I would find this behavior to be strange and unexpected.

In contrast, the current module block behavior (no caching) is more in line with function literals or object literals behave:

runInWorker(() => {})
// vs
let h = () => {}
runInWorker(h)

Most developers know that closures (or object literals) can be expensive and need to be manually hoisted in hot-paths. The same logic would apply to module blocks:

const m = module { ... };
onclick = () => runInWorker(m);

Additionally, one of the goals of this proposal is to be a building block for future scheduler-like libraries and platform-level proposals. Let’s pretend such a scheduler exists that implements the Actor Model, where the location of the code execution is abstracted away from the developer.

If we wanted to spawn 10 actors executing the same code, caching by source position could have the unintended side-effect that multiple actors end up sharing state just because they end up on the same thread.

for(let i = 0; i < 10; i++) {
  spawnActor(module { /* ... */ });
}

I talked to @littledan as well and we are contemplating to weakly hold module blocks in the module map, which allows them to be cleaned up throughout the lifecycle of a document.

[esprehn]

Would it be possible to make the return value of module {} be the same object based on source position, but import() create a new weakly held module in the map each time? That way you can put a caching layer over top if you want since the module has a stable object identity (like urls today) even if each time you call import() you get a different result.

const cache = new Map();

function cachedImport(m) {
  const result = cache.get(m) || import(m);
  cache.set(m, result);
  return result;
}

for (let i = 0; i < 100; ++i) {
  const m = module {};
  assert(await cachedImport(m) === await cachedImport(m));
  assert(await import(m) !== await import(m));
}

Maybe that's too weird, but I think it's nice to not have to back derive the "url" of a module block.

[jkrems]

I would compare it to template literals which also has some notion of cache-by-position. I'm a bit concerned about accidental memory leaks if anything keeps previously initialized module bodies alive.

I'm concerned about innocent looking refactors like:

// Before:
async function getStuff() {
  const stuff = await import('./helper.mjs');
  return stuff.default;
}

// After:
async function getStuff() {
  const stuff = await import(module {
    // This was a one-line helper file, this is so much simpler!
    export default 42;
  });
  return stuff.default;
}

If the return value is retained, this would now keep leaking copies of that module record even though the underlying assumption of the refactor ("import imports once") was fairly reasonable today.

[nicolo-ribaudo]

@jkrems I don't think I understand which option you are supporting 😅

• If it will be "cache by position", it will leak a single module and not multiple copies
• If it will be "don't cache", every module will be garbage-collectable as soon as getStuff returns.

[ljharb]

That example to me is a compelling argument for why it must be cached by position; module exports can have identity and that identity can be important.

[jkrems]

Returning a primitive was a poor choice to illustrate the problem. The problem appears only really if it would be for example a closure that closes over the module scope (e.g. accesses import.meta).

[Jack-Works]

Possible solution:

Add a unique (prior art symbol vs unique symbol in typescript) modifier to tell which the semantics should be use.

const x = [0,1].map(() => unique module {})
// two different module. Need opt-in cause performance trap
const y = [0,1].map(() => module {}) // the same module

Does anyone interested in my solution to this problem? Default cache-by-position and opt-in unique module each evaluation.

[leobalter]

const unique = module { /**/ };
const y = [0,1].map(() => unique);

I don't think there is a need to have 2 distinct ways to declare a module and keep it unique while you can store a module in a reusable name.

[ljharb]

@leobalter that wouldn't make it unique - ie, y would have two of the same module, instead of two distinct modules.

[Jack-Works]

const unique = module { /**/ };
const y = [0,1].map(() => unique);

I don't think there is a need to have 2 distinct ways to declare a module and keep it unique while you can store a module in a reusable name.

The problem here is, the default behavior currently is unique module each evaluation, which might be a footgun on memory (initialize a new module every time).

[leobalter]

I'm actually sleep deprived right now because of the current meeting time but let me try to rephrase how I see this:

const x = [0,1].map(() => module {/* unique */}); // new module here

const same = module { /**/ };
const y = [0,1].map(() => same); // reuse the same module

and yet it seems like user responsibility to control the code and something handled by a linter. This happens with other literal/expression values, so the potential memory footgun model already exists:

[0,1].map(() => function() { /* a new function for each entry */ });
[0,1].map(() => [ /* a new array for each entry */ ]);
[0,1].map(() => ({ /* a new object for each entry */ }));

Having a module fragment/block seems like any other literal/expression value.

[ljharb]

I agree if behavior is not "cache by position" but is instead "uncached", then "unique" is just "make a variable in a higher scope".

However, "cache by position" seems like a reasonable default, per above discussions.

[leobalter]

cache-by-position seems way more confusing, IMO.

function fn() {
  return module {
    let x = 0;
    export default function() {
      x++; // side effects
      return x;
    }
  };
}

const a = fn();
const b = fn();

a === b; // ?

// now think code here evaluating and using the modules from a and b.

[ljharb]

In this case, with caching, a === b would be true, and that the module has side effects is exactly why it's important that it be preserved. I think that it would be very confusing in practice if every time you called fn you created a distinct stateful module.

This is somewhat related to the peerDependencies issue in npm module graphs.