Proposal: Rename “loaders”

[GeoffreyBooth]

In many of the discussions on this repo and in https://github.com/nodejs/node, we’ve considered various parts of Node that users might want to customize beyond just module resolution and loading. Within this repo one major use case discussed has been virtual filesystems, which would require hooking into many (if not all) of the fs methods. In nodejs/node#43818 (comment) @cspotcode has compiled a great (incomplete) list of places where someone adding support for TypeScript to Node might want to customize Node:

• repl
  • tab completion (current api insufficient)
  • top-level await (mechanism not exposed)
• inherit configuration blob to worker_threads and child_processes (currently requires hacks)
• stack trace support (fix bugs & perf in node’s current implementation)
• stack trace cache setter (haven’t looked at this one in a while)
• proper APIs into node’s CJS exports discovery mechanism (discover ESM named exports in CJS source code, no way for transpiled code to contribute to this process)

I’m thinking perhaps a better name for this repo and the Loaders API itself would be “hooks” / Hooks API. This would better reflect even the existing API, since arguably globalPreload has little to do with module resolution and loading. We could also move the loaders documentation out of the ESM page in the docs and into its own page. cc @nodejs/loaders

If the current loaders team likes this idea, I can open an issue on nodejs/admin to make it happen from a technical standpoint.

---

Update per #95 (comment), here are the new names:

• Team: “Customization.” (Likewise for this repo, GitHub group, etc.)
• Docs: new top-level section “Customization API.” Move “ESM » Loaders » Hooks” to “Customization API » Module Hooks”.
• Flag(s): No change for now, but reevaluate as part of moving loaders off-thread.

[JakobJingleheimer]

I think this sounds like a sound idea. It enormously expands our scope/purview though.

[GeoffreyBooth]

I think this sounds like a sound idea. It enormously expands our scope/purview though.

Well I think those other things were already part of our scope 😄 just informally so.

[GeoffreyBooth]

cc @nodejs/tsc for awareness and permission. I can give an update at the next TSC meeting.

[mcollina]

I'm +1 on a terminology change, but I'm not sure we can use hooks as we already have async_hooks and performance_hooks. These might be loader_hooks possibly?

[JakobJingleheimer]

I'm not sure we can use hooks as we already have async_hooks and performance_hooks.

Ah, good shout. I definitely don't want to be responsible for asnyc_hooks 😵‍💫

[cspotcode]

Should definitely consider a single CLI flag that is empowered to make all necessary runtime customizations. It fits the goals of nodejs/node#43818 and nodejs/node#43408: runtime customization with good user-experience, acknowledging that TS support (and other stuff) requires more than just loader hooks. Splitting hook registration mechanisms across multiple CLI flags feels like bad user experience.

[GeoffreyBooth]

I'm not sure we can use hooks as we already have async_hooks and performance_hooks.

Ah, good shout. I definitely don't want to be responsible for asnyc_hooks 😵‍💫

Then customization_hooks? At least for the namespace, if we even need one; and --hooks for the flag?

"Loader hooks" doesn't make sense because many of the types of customization people want to do don't involve loaders.

[JakobJingleheimer]

Then customization_hooks? At least for the namespace, if we even need one; and --hooks for the flag?

Hrrm, I think we can't use --hooks for the reason Matteo cited :( Although, I do like it.

I don't love customization_hooks 😅 hooks are inherently customisation, so that just adds letters. These are things that affect how node sets itself up, so maybe… init-hook, setup-hooks, or startup-hooks?

[arcanis]

integration_hooks? language_hooks?

[GeoffreyBooth]

Hooks aren't inherently customization. Async hooks and performance hooks aren't about customizing Node.

Also the hooks are registered during startup but they apply to the lifetime of the process. I don't see them as related to startup.

[Qard]

Naming things--the hardest problem in computer science. 😅

Seriously though, I think the current "loaders" naming is fine until we actually specify how the system is expanding. The eventual shape of this subsystem is very nebulous. I don't think the right name for it will be clear until that lack of scope clarity is resolved.