Have presentation on loaders.

[bmeck]

We have a fair number of features being related to loader hooks. I'd like to add an agenda item to either an upcoming meeting or to schedule a time to present about what loaders are/can do. Right now they seem to lack concrete definition or explanation and it is possible that this will lead to confusion as we move forward.

I've prepared some slides explaining the terms to the best of my ability: a small review of requirements, review of current loader hooks, and some thoughts on a part to refactor them based upon some research I am currently doing. I will be continuing research and nothing should be seen as a hard path forward.

Feel free to comment on the slide deck I have as we are mostly trying to reach some sort of consensus and am happy to rephrase or add content as desirable. I think the important thing in this is to discuss the what of Loaders with relation to ESM so that we get a clear distinction of what is and is not a Loader. We pass around the phrase "it just works" but we should go into depth about how it works and should be careful to not allow that phrase to be a means to ignore details as we move towards and beyond feature discussions.

[xtuc]

Btw if you're looking for example, I made a WASM loader here: https://github.com/wasm-tool/node-loader

Note that wasm instantiation can block some time due to executin the start function or memory initialization.

[viktor-ku]

@bmeck again I disagree with this approach. I believe it will create a lot of headache in the future since we are about to call all loaders for every import instead of calling the loader only if it's necessary

• It will make loaders code more clean and loader-specific, because loader will handle one specific import type
• Loader won't need to have checks of any kind, because it will be called only if it's needed

[xtuc]

What would be your suggestion @viktor-ku? (I've might missed it from previous discussions). I can imagine a fixed list of extension or regexep but that won't be as generic as currently.

all loaders

We don't expect to have many loaders? (20 would already be a lot to me).

[viktor-ku]

@xtuc updated comment above

[xtuc]

@viktor-ku one of my question was how do you call only the necessary loaders?

• Based on a list of known extension? Limitating.
• Based on provided regexp? Slow.

[viktor-ku]

@xtuc I guess you're right. It's slow. And I don't have any other ideas

[Janpot]

You could also decide to allow only one loader in node and write loaders in userland that can compose multiple loaders together.

[bmeck]

@Janpot the problem with doing that is how composition works. If I have only a single loader how do I add to it. Imagine:

node --loader jspm index.mjs

And now I want to run my application with code coverage:

NODE_OPTIONS='--loader code-coverage'
node --loader jspm index.mjs

Use cases where you need loaders to coordinate are easy enough to show that we can't just have a single uncomposable loader. We could defer the composition to userland but that comes at the cost of not solving use cases with our default solution.

[Janpot]

Maybe you add the multiloader and push jspm deeper?

MULTILOADER_OPTIONS='code-coverage jspm'
node --loader multiloader index.mjs

But I see your point.

[bmeck]

@Janpot possible, but that just devolves into everyone needing to use multiloader at which point we should just ship as minimally invasive form as is possible so that people could implement their own multiloader as part of the loader chain.

[Janpot]

Yes, I agree. I just remember seeing a comment somewhere that they wanted to do in core only what can't be done performantly in userland. But this would indeed take that a bit too far.

edit:

The main benefit I see in doing the multiloader is that you can push the cognitive overhead of figuring out the right behavior forward to after the initial release of ESM. At which point you can still implement the solution that the community converges too.

Then again, you could treat the whole implementation this way and push forward a lot of use-cases in this repo. Personally it would be the approach I'd go for, but I understand people want a complete implementation with sane defaults from the get go. (I don't want to create more noise in this issue as I'm not a member so you can safely ignore this philosophical side-track.)