feat(DEP0205): migrate compatible module hooks to `module.registerHooks()`

Abierto
#561 1 comentario 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
devtools, tooling

Línea de trabajo

Start by locating the codemod entry point and fixtures for module.register() calls; trace how it can inspect both the registration site and each referenced local hook module. Define conservative checks for compatible synchronous resolve hooks and preserve registration-before-application loading order. Done means supported cases are transformed and fixtures cover aliases, unresolved specifiers, unsupported hooks, and load order, while unsafe cases are skipped or reported.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

module.register() became runtime-deprecated in Node.js 26.0.0 under DEP0205. The replacement is module.registerHooks().

This is not a direct function rename. register() loads hook implementations on a separate loader thread, while registerHooks() receives synchronous hook functions that execute on the thread loading the modules.

Add a partial migration for local hook modules whose behavior is compatible with synchronous, same-thread execution. The codemod must inspect both the registration site and the referenced hook module before proposing edits.

Additional Information

  • Start with literal local module specifiers and simple, stateless resolve hooks that already use synchronous control flow and return plain objects or the result of nextResolve().
  • Introduce an import of the supported hook function and pass it through registerHooks({ resolve }), preserving binding names and avoiding collisions.
  • Preserve loading order: application modules that need customization must still be loaded after hook registration, using dynamic import() or an appropriate require().
  • Moving the hook module to the main thread can change its initialization order, global state, side effects, and interaction with other registered hooks. Skip cases where compatibility cannot be established.
  • Skip hooks using initialize, transferred data, MessagePorts, asynchronous I/O, unresolved dependencies, or thread-specific behavior.
  • Do not remove async or await mechanically. Async load hooks, CommonJS-specific behavior, mixed hook chains, and worker inheritance need separate analysis.
  • Programmatically registered synchronous hooks are not inherited by child workers in the same way as asynchronous hooks. Report applications relying on that inheritance; preloaded registration files require their own review.
  • Keep existing registerHooks() calls unchanged. Include fixtures for supported local hooks, aliases, unresolved module specifiers, unsupported hooks, and application load order.

Examples

For a local hooks.mjs containing only a compatible stateless resolve export, the registration file can change as follows:

-import { register } from 'node:module';
+import { registerHooks } from 'node:module';
+import { resolve } from './hooks.mjs';

-register('./hooks.mjs', import.meta.url);
+registerHooks({ resolve });
 await import('./app.mjs');

Example compatible hooks.mjs, unchanged by this migration:

export function resolve(specifier, context, nextResolve) {
  if (specifier === 'app:config') {
    return {
      url: new URL('./config.mjs', import.meta.url).href,
      shortCircuit: true,
    };
  }
  return nextResolve(specifier, context);
}

This example assumes that the hook module has no initialization effects or dependencies on loader-thread isolation, existing hook chains, or worker inheritance. More complex modules should be reported for manual migration.

Refs

Lenguaje dominante
TypeScript
Estrellas
85
Forks
58
Merge medio
2 d 4 h
PR fusionados (30 d)
6

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nodejs/userland-migrations

Todos los issues de nodejs/userland-migrations

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.