No estoy seguro de si esto es factible o si pertenece al repositorio de Node.js.

Qué? Por qué

A menudo hay casos en los que ciertas dependencias requieren configuraciones de compilación específicas para funcionar correctamente en un entorno general (por ejemplo).

Esta configuración puede ser una configuración de Babel, una configuración de Webpack o algo personalizado solo para ese paquete.

Tal como está actualmente, no existe una forma estandarizada de configurar paquetes.

Algunas personas usan una convención en la que colocan un campo en package.json nombre del paquete, y un paquete puede leer eso. Pero no se siente lo suficientemente estándar.

Cuando

Cuando un paquete necesita una configuración personalizada para el tiempo de ejecución o el tiempo de compilación.

Dónde

Cómo

A veces ocurre que JavaScript necesita pasos de compilación para ciertos casos. Esta característica de configuración tendría una opción opcional de "construir dependencias" que se puede pasar a cualquier paquete (ya sea que construyan módulos nativos o simplemente transpilen JavaScript a un formato inferior).

Dependiendo de la configuración, un paquete puede necesitar ciertas dependencias que de otro modo no necesitaría (por ejemplo, dependencias de compilación).

Entonces, el sistema de paquetes sería lo suficientemente inteligente, ya que si un usuario tiene cierta configuración de paquete, puede determinar qué dependencias adicionales instalar.

Quizás esta característica solo necesita expandirse del sistema de módulos nativos existente al sistema JavaScript general (de una manera fácil de usar, los módulos nativos son complicados).

Esto también podría ser muy útil para cosas como dependencias opcionales. Sería fácil, con config, especificar que una biblioteca use (por ejemplo) three lugar de babylonjs . Esto haría que se instalara la dependencia adecuada. Es similar a las dependencias de pares, pero más fácil, y un paquete dado que depende de deps opcionales tendría una forma estándar de acceder a la API de configuración de manera confiable para determinar si se especifican ciertas condiciones (actualmente es complicado, y cualquier recorrido de cystom de node_modules no es- estándar en estos casos).

Comportamiento actual

• n / A

Comportamiento esperado

• cubierto arriba a un alto nivel

Como otro ejemplo, a veces los consumidores de paquetes necesitan consumir la fuente del paquete en lugar de la salida compilada habitual para compilar el código de diferentes maneras (por lo general, me encuentro con ganas de hacer esto con Webpack).

En general, hay problemas con ese tipo de cosas, que hasta ahora NPM no proporciona una forma común de manejar.

OMS

autores de paquetes y sus usuarios

Referencias

• n / A