¿Qué son los archivos `rc` en nodejs?

Tengo algunas preguntas sobre varios rcarchivos en una aplicación de nodo típica, como .npmrc, .babelrcetc.

• ¿Qué es un archivo rc, sé que es una configuración en tiempo de ejecución para el módulo, pero algo más?
• ¿El archivo rc tiene que seguir la .[module]rcconvención de nomenclatura o es solo un formato recomendado?
• ¿Cuáles son los formatos compatibles? He visto formatos yaml y json, ¿depende del lector que use el módulo?
• ¿Cómo acceder a un archivo rc desde la perspectiva de un módulo? ¿Nombrarlo como [module]rclo haría automáticamente disponible para el módulo? Si es así, ¿dónde estará disponible?
• ¿O debería el módulo acceder al archivo como cualquier otro archivo de la aplicación que está usando el módulo y esperar que esté en un formato comprensible? (Esto es lo que estoy haciendo ahora mismo, con formato json)
• También he visto personas que requieren package.jsoncargar config. ¿Cuál se recomienda package.jsono un archivo rc?
• Además, ¿en qué se diferencia de un archivo javascript como gulpfile.jscon module.exports? (Me refiero en el sentido de recomendaciones, por supuesto que conozco la diferencia y las ventajas de los archivos js y rc)

Cada vez que busco en google, termino aquí y aquí , que es una herramienta para leer archivos rc pero no explica qué son o cómo están construidos y / o conectados al módulo.

Cualquier idea sería realmente útil. Gracias

Así que primero que nada, muy bien preguntado.

rcdotfiles son archivos de configuración que pueden variar en su uso, formato y significado general. Puede crear .[whatever name you like]rcarchivos para informar cualquier paquete que esté creando (siempre que otro paquete no esté buscando el mismo). Por lo general, son útiles para algún tipo de herramienta que actúa sobre su código fuente y necesita algunos ajustes específicos para su proyecto. Tengo entendido que hubo archivos similares que jugaron un papel importante en los sistemas UNIX en años pasados ​​y la idea se ha quedado.

En breve:

• No son específicos del nodo.
• Son solo otro archivo
• En cuanto a los formatos, pueden ser casi cualquier cosa, solo depende de lo que use para analizarlos y leerlos. YAML, JSON e ini son probablemente los más comunes (al menos lo que he visto).
• En la mayoría de los casos, parecen seguir la convención. .[program or binary name]rc
• package.jsonlos archivos pueden contener metadatos externos apropiados para la configuración, solo depende de si su proyecto esperará o no un .rcarchivo o lo esperará en package.json(o ambos, como en el caso de babel)

Ver también:

• ¿Qué significa "rc" en archivos dot
• http://www.faqs.org/docs/artu/ch10s03.html#ftn.id2941902
• https://en.wikipedia.org/wiki/Configuration_file

Como ejemplo increíblemente simple:

Supongamos que desea leer este .foorcarchivo que usa codificación JSON:

{
  "cool": true
}

Podrías hacer algo como esto:

'use strict';
const fs = require('fs');
fs.readFile('./.foorc', 'utf8', (err, data) => {
  if (err) throw new Error(err);
  console.log(JSON.parse(data));
})

Hay formas mucho, mucho mejores de hacer esto, pero podría fácilmente escribir el suyo propio o encontrar un paquete que admita el análisis de YAML, ini, etc. y también proporcione algunos otros bits agradables de una API (por ejemplo, rc )

No es específico de Node o Babel, pero los *rcarchivos son generalmente archivos de configuración en sistemas Unix

De Wikipedia

Los archivos de configuración también hacen más que modificar la configuración, a menudo (en la forma de un "archivo rc" ) ejecutan un conjunto de comandos al iniciarse (por ejemplo, el "archivo rc" de un shell puede indicarle al shell que cambie de directorio, ejecutar ciertos programas, eliminar o crear archivos - muchas cosas que no implican modificar variables en el propio shell y por lo tanto no estaban en los archivos dotfiles del shell). Esta convención se toma prestada de "archivos runcom" en el sistema operativo CTSS.

Esta funcionalidad puede y ha sido extendida para programas escritos en lenguajes interpretados de tal manera que el archivo de configuración es en realidad otro programa que reescribe, extiende o personaliza el programa original ; Emacs es el ejemplo más destacado.

La convención de nomenclatura "rc" de los "archivos rc" se inspiró en la función "runcom" mencionada anteriormente y no significa "configuración de recursos" , "configuración en tiempo de ejecución" o "control remoto" como se suele adivinar erróneamente.

Los archivos "rc" son tradicionalmente archivos que terminan en el sufijo "(.) rc" y que contienen datos e información que se utiliza como información de configuración para el programa asociado. Normalmente, el nombre de ese programa es la primera parte del nombre del archivo rc, con el sufijo "(.) Rc" que se utiliza para indicar el propósito del archivo, por ejemplo, ".xinitrc" , ".vimrc" , ".bashrc" , " xsane.rc " .

Y Runcom

Unix: desde archivos runcom en el sistema CTSS 1962-63, a través del script de inicio / etc / rc

Archivo de script que contiene instrucciones de inicio para un programa de aplicación (o un sistema operativo completo) , generalmente un archivo de texto que contiene comandos del tipo que podrían haber sido invocados manualmente una vez que el sistema estaba en ejecución, pero que deben ejecutarse automáticamente cada vez que se inicia el sistema. Véase también archivo de puntos.

En otras palabras, "rc" es algo que se mantuvo en los años sesenta y se ha utilizado con bastante frecuencia para archivos de configuración en diferentes tipos de programas desde entonces, incluidos Node, Babel y muchos, muchos otros.

Los archivos "rc" no tienen nada de especial y prácticamente pueden contener cualquier tipo de datos, no hay especificaciones ni otras restricciones.

RC se refiere a

• ejecutar comandos
• configuración en tiempo de ejecución

https://en.wikipedia.org/wiki/Run_commands

El sufijo 'rc' se remonta al abuelo de Unix, CTSS. Tenía una función de secuencia de comandos llamada "runcom". Los primeros Unixes usaban 'rc' para el nombre del script de arranque del sistema operativo, como un tributo a CTSS runcom.