Loaders Team
Purpose
The Node.js Loaders Team maintains and actively develops the ECMAScript Modules Loaders implementation in Node.js core.
History
This team is spun off from the Modules team. We aim to implement the use cases that went unfulfilled by the initial ES modules implementation that can be achieved via loaders.
Project
Status
-
Finish nodejs/node#37468 / nodejs/node#35524, simplifying the hooks to
resolve,loadandglobalPreloadCode. -
Refactor the internal Node ESMLoader hooks into
resolveandload. Node’s internal loader already has no-ops fortransformSourceandgetGlobalPreloadCode, so all this really entails is wrapping the internalgetFormatandgetSourcewith one functionload(getFormatis used internally outside ESMLoader, so they cannot merely be merged). nodejs/node#37468 -
Refactor Node’s internal ESM loader to move its exception on unknown file types from within
resolve(on detection of unknown extensions) to withinload(if the resolved extension has no defined translator). nodejs/node#37468 -
Implement chaining as described in the design, where the
default<hookName>becomesnextand references the next registered hook in the chain. nodejs/node#42623 -
Convert
resolvefrom async to sync nodejs/node#43363- Add an async
resolvetomodulemodule
- Add an async
-
Add helper/utility functions (eg
getPackageType()) tomodulemodule -
Move loaders off thread
-
Support loading source when the return value of
loadhasformat: 'commonjs'. See nodejs/node#34753 (comment) and https://github.com/nodejs/loaders-test/blob/835506a638c6002c1b2d42ab7137db3e7eda53fa/coffeescript-loader/loader.js#L45-L50. -
First-class support for import maps that doesn’t require a custom loader.
After this, we should get user feedback regarding the developer experience; for example, is too much boilerplate required? Should we have a separate transform hook? And so on. We should also investigate and potentially implement the technical improvements on our to-do list.