Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time
November 6, 2023 11:19
April 19, 2021 22:48
April 19, 2021 22:48
April 19, 2021 22:48
November 21, 2023 20:20

Loaders Team


The Node.js Loaders Team maintains and actively develops the ECMAScript Modules Loaders implementation in Node.js core.


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.



Milestone 1: Parity with CommonJS

Before extending into new frontiers, we need to improve the loaders API enough that users can do just about everything they could do in CommonJS with ESM + loaders. (Outside of loaders scope, but related to the goal of parity between CommonJS and ESM, is finishing and stabilizing --experimental-vm-modules.)

Milestone 2: Stability

Milestone 3: Usability improvements

  • Provide a way to register loaders via configuration, for example via adding support for .env files to Node.js or having node read configuration from a new field in package.json or other configuration file. See nodejs/node#46826, #98, nodejs/node#43973 (comment). nodejs/node#48890.

  • Integrated support for external formats.

    • Phase 1: Support identifying external modules (eg typescript); see nodejs/node#49704.
    • Phase 2: Support guided remediation via package manager search (eg npm search … typescript).
    • Phase 3: Automatically configure Node.
  • First-class support for import maps that doesn’t require a custom loader.

  • Add helper/utility functions to reduce boilerplate in user-defined hooks.

    • Start with helpers for retrieving the closest parent package.json associated with a specifier string; and for retrieving the package.json for a particular package by name (which is not necessarily the same result).

    • Potentially include all the functions that make up the ESM resolution algorithm as defined in the spec. Create helper functions for each of the functions defined in that psuedocode: esmResolve, packageImportsResolve, packageResolve, esmFileFormat, packageSelfResolve, readPackageJson, packageExportsResolve, lookupPackageScope, packageTargetResolve, packageImportsExportsResolve, patternKeyCompare. (Not necessarily all with these exact names, but corresponding to these functions from the spec.)

    • Follow up with similar helper functions that make up what happens within Node’s internal load. (Definitions to come.)

  • Helper/utility functions to allow access to the CommonJS named exports discovery algorithm (cjs-module-lexer).

  • Hooks for customizing the REPL, including transpilation and tab completion. Support users pasting TypeScript (or CoffeeScript or whatever) into the REPL and having just as good an experience as with plain JavaScript.

    • Support top-level await in the REPL API, if possible.
  • Allow customizing string inputs: --eval CLI flag, Worker constructor, stdin, etc.

  • Hooks for customizing the stack trace (in other words, a hook version of Error.prepareStackTrace). This would allow transpiled languages to improve the output.

  • Hooks for customizing filesystem calls, for allowing things like virtual filesystems or archives treated as volumes.

  • Inherit configuration blob to worker threads and child processes.