Estoy construyendo un sistema de nodo distribuido relativamente complejo. Digamos que hay dos procesos (aplicaciones de nodo), A y B. Se definen en proyectos separados.
Además, hay un par de módulos de nodos personalizados que se usan tanto en A como en B. Llamémoslos M y N. Además, M usa N.
¿Cómo debo manejar correctamente las variables ambientales?
Supongo que debería definir .env para ambos procesos principales (A y B), manejar todas las variables ENV desde allí y simplemente pasar las variables env necesarias desde allí, hasta M y N. De esta manera, M y N (y otros módulos internos ) recibirán sus propios ENV vars pasados como parámetros en la creación.
¿Es correcto este enfoque?
Tener módulos que tengan acceso directo a process.env no es una buena idea, y los módulos que tienen su propio archivo .env es una idea aún peor.
Los archivos .env no deben agregarse al control de fuente (es decir, git) porque cambian con el entorno ( dev , prod , pre-prod ) y, a veces, contienen información confidencial (como claves secretas de AWS) . Eso requeriría que pegue un archivo .env cada vez que instale sus node_modules , lo que hace que su proceso de implementación sea más complejo.
El archivo .env cargado dentro de su módulo podría fusionarse de formas inesperadas con el .env de su aplicación raíz (recuerde que solo hay un process.env ) .
Imagine un caso en el que su módulo deba comportarse de manera diferente en dos partes de su aplicación. ¿Cómo anularía los datos cargados a través del archivo .env solo en un lugar?
Entonces, en mi opinión, su suposición es correcta: no ponga .env en node_modules .
// This is better... nModule.someMethod(process.env.PARAM1, process.env.PARAM2); // ...than this process.env.PARAM1 = ''; process.env.PARAM2 = ''; nModule.someMethod();Su enfoque suena correcto y debería funcionar. Cuando defina el archivo .env y use el paquete dotenv , podrá acceder a todas las variables dentro de .env en su código. Eso significa que los módulos de nodos personalizados también podrán acceder a él, y no tiene que pasarles nada (puede acceder a ellos directamente con process.env.NAME_OF_ENVIRONMENT_VARIABLE ).
SUMERIZE: Cree un archivo .env tanto en A como en B, use el paquete dotenv y luego podrá acceder a las variables de entorno directamente dentro del código con process.env.NAME_OF_ENVIRONMENT_VARIABLE (también en módulos de nodos personalizados). Puede crear un constructor (para módulos personalizados) en los módulos A y B, y simplemente pasar process.env.ENV_WHATEVER como parámetro. Ese es un enfoque aún mejor ya que la lógica de su módulo personalizado será independiente del resto de la aplicación (dependerá solo de la entrada).
NOTA: No envíe su .env a Git, ya que .env generalmente tiene información confidencial. La mejor práctica es crear un archivo .gitignore y agregarle .env .
RECOMENDACIÓN Puede mantener todos sus archivos .env en un lugar centralizado para una mejor administración. Puede consultar algunas herramientas de administración de contraseñas como https://www.dashlane.com/ o https://www.lastpass.com/ .
Creo firmemente que las variables de entorno están reservadas para, bueno, el entorno. Esto para mí implica algunas cosas:
process.env .process.env es realmente una cuestión de cómo inicia sus programas A y B. Personalmente, prefiero los servicios de systemd que tienen un excelente soporte para definir el entorno de tiempo de ejecución. El paquete dotenv parece más una muleta, pero está bien desde la perspectiva del programa.