Plan of process.binding() deprecation

Abierto
  • ¿Algo no está bien?
#1,482 18 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
javascript, node.js
Área
backend

Línea de trabajo

Comienza revisando los pull requests de Node.js referenciados y las preguntas sobre el comportamiento del estado final, el despliegue del binding, las alternativas y el momento de la advertencia. Se considera completado cuando el TSC haya resuelto estas preguntas y documentado un plan de deprecación acordado; no se nombran archivos de implementación ni pruebas.

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

Descripción

This issue is not new but motivated by https://github.com/nodejs/node/pull/50687, which proposed to

  1. Ship the runtime deprecation in Node.js v22 --deprecated-process-binding on by default.
  2. --no-deprecated-process-binding becomes the default in Node.js v23
  3. process.binding(...) is removed entirely in Node.js v24, with the CLI option becoming a no-op

For background in 2021 the plan suggested in https://github.com/nodejs/node/pull/37485#pullrequestreview-600060802 and followed since https://github.com/nodejs/node/pull/37819 was:

  1. Do comprehensive research into what exact features ecosystem modules get through process.binding() (this isn't actually going to be a huge API surface!)
  2. Patch process.binding() so that it returns objects that cover those use cases, implemented in terms of public APIs
  3. Optionally, runtime-deprecate process.binding() only for the cases that users aren't commonly encountering
  4. Eventually, remove support for those cases specifically
  5. Leave it at that, don't runtime-deprecate process.binding() as a whole and leave the shim in place forever

I am opening this issue trying to slice the issue into different questions instead of bundling all together into just two different plans, in the hope of figuring out a better compromise.

There are several questions to the deprecation of process.binding():

  1. What's our end-goal when the deprecation reaches EOL?
    a) Delete process.binding completely so that when trying to invoke it, users get an error.
    b) A function that does no more than emitting a warning and returning empty objects. Users almost always get an error when they try to access an unsupported property, but if the code path is unused, e.g. only loading a process.binding() from the top-level but never actually hit the code path using anything from it, it would not fail.
    c) Leave a low-maintenance and harmless shim in place forever. Users get an error only when they try to use a specific unsupported property.
  2. How should the list of bindings (currently 20) be deprecated?
    a) Individually, based on how problematic they are/how difficult it is to provide alternatives
    b) Together at once
  3. Should the runtime deprecation start before or after alternatives/shims are completed
    a) We investigate the impact (e.g. through CITGM), develop and release alternatives on the way, monitor the changes in the impact, before deciding when it's ready to runtime-deprecate it (individually or all together).
    b) Runtime-deprecate it directly and mitigate the impact afterwards based on the bug reports/feature requests we receive.
  4. How should the warnings be rolled out when we start to emit warnings (there are a few more combination possibilities with 2)
    a) Emit runtime warnings unconditionally
    c) Non-node_module warnings first, node_module warnings in the next cycle

I think we as @nodejs/tsc need to take a deeper look into these questions and make some decisions before finishing a plan of the deprecation.

Lenguaje dominante
JavaScript
Estrellas
693
Forks
142
Merge medio
8 d 7 h
PR fusionados (30 d)
3

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/TSC

Todos los issues de nodejs/TSC

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.