Modules: Cancellation and ESM?

[benjamingr]

Hey,

I'm working on a potential non committing list for potentially adding AbortController support to Node.js (there is also a summit meeting everyone is invited to).

This is mostly just a high level discussion and exploration of the problem domain.

One thing I'm doing is going over modules in core and figuring out how cancellation might apply to them.

Does cancellation apply to ESM in any way? Is it possible to abort a dynamic import in any meaningful way? (That would actually abort the underlying request?)

(Feel free to point me to a wall of text if this was discussed in the past I was unable to find such a discussion).

[benjamingr]

Also cc @nodejs/modules-active-members :]

[devsnek]

I don't think cancellation fits into module loading very well, at least because racing a successful import being cached with being cancelled could end up confusing someone.

[benjamingr]

I don't think cancellation fits into module loading very well

I actually think it can be _probably_ be done well (hand waving follows) by allowing cancellation and passing a signal or token to the import and it only gets cached if the import succeeds (and if there are multiple imports for the same resolved identifier cancellation ref-counts or something).

I think that even if we _can_ make such an API work well - Node shouldn't ship it without TC39.

[giltayar]

@benjamingr if this happens, you probably also need to pass that signal to the module in question because top-level await means that the user is also executing async code that may need to be aborted.

[targos]

import() is not a function. It's a syntax error to pass more than one parameter, so this feature would definitely have to come from the spec/V8.

[bmeck]

I think the only real use case for cancellation is racing parallel graphs which doesn't seem to be a big priority for Node. In such an example you could imagine (forgive the bikeshed syntax):

await import.meta.race([
  'a.node',
  'a.wasm',
  'a.js'
]); // just grab any of them, don't care

for the web this is much more appealing with the idea of "fallback" imports where you might race CDNs for an import. By "cancelling" you could prevent any further work in the Module Job infrastructure, but likely we wouldn't discard entries since you don't know if in the future they would be used. I'm not sure I understand the use case for cancelling imports beyond such racing / fallbacks. However, to implement such an API would require spec changes or likely hanging something off of import.meta which in general is risky if it is not cross-environment compatible.

[bmeck]

given the feedback I'm closing for now until something changes such as a TC39 proposal at which point it might make more sense to open a new issue on integrating with the feature that revives this issue rather than a more general issue such as this