.jpg)
Si has escrito código en Node.js probablemente te hayas encontrado con algo como esto: if ( process.env.NODE_ENV === production ) { app.use(rateLimiter); } o if ( process.env.NODE_ENV === development ) { console.log( Debug , data ); } Este enfoque es un patrón antipatrón. La documentación oficial de Node.js advierte que usar NODE_ENV para todo menos producción suele ser mala práctica.
El problema radica en que al ramificar el comportamiento de la aplicación en función del nombre del entorno estás ligando la lógica a una etiqueta y no a la configuración real que necesita tu aplicación. Esto crea un problema fundamental para las pruebas: los tests no verifican lo que realmente se ejecuta en producción.
La trampa de las pruebas: Un patrón común es if ( process.env.NODE_ENV === production ) { app.use(rateLimiter); app.use(helmet()); logger.level = error; } else { logger.level = debug; } Si tus pruebas se ejecutan con NODE_ENV=test nunca alcanzarán la rama de producción. Los tests pueden pasar pero no tienes forma de comprobar si el rate limiter está bien configurado, si helmet rompe las respuestas de la API o si el registro de errores funciona en producción. Estás probando una aplicación distinta a la que usan tus usuarios.
La pesadilla del staging: El problema empeora con entornos de staging. Deseas que staging refleje producción para pruebas realistas pero también necesitas diferencias como bases de datos o APIs externas alternativas. Con NODE_ENV estás obligado a elegir: si pones NODE_ENV=production en staging podrías activar funciones exclusivas de producción que no quieres, como procesamiento de pagos. Si pones NODE_ENV=staging tu código que solo comprueba NODE_ENV === production tratará staging como desarrollo. No puedes tener staging que se comporte como producción para pruebas y a la vez ser distinto para despliegue. NODE_ENV te fuerza a una elección imposible.
La solución: En lugar de comprobar el entorno comprueba la característica o la configuración que necesitas. En vez de if ( process.env.NODE_ENV === production ) { app.use(rateLimiter); } usa una bandera explícita como if ( process.env.ENABLE_RATE_LIMITING === true ) { app.use(rateLimiter); } De esta manera tus tests pueden activar las mismas características que usarás en producción y verificar su comportamiento real.
Y qué pasa con las librerías: Algunas librerías como React y Express utilizan NODE_ENV para activar mejoras de depuración o mensajes adicionales. Eso está bien y puedes confiar en ello durante el desarrollo. Ten en cuenta que NODE_ENV distinto de production debería utilizarse solo para habilitar esas características a nivel de librería y no para controlar la lógica propia de la aplicación. Usa NODE_ENV de forma intencional, conoce qué harán las librerías con ese valor y evita tratarlo como un interruptor universal.
Si necesitas conocer el entorno: A veces necesitas identificar el entorno para logs, monitorización o para mostrar información. En ese caso utiliza una variable distinta como APP_ENV. Por ejemplo const environment = process.env.APP_ENV || development; console.log( Running in + environment + environment ); De este modo NODE_ENV queda reservado para librerías y APP_ENV es la forma clara de que tu aplicación identifique el entorno. Sigue usando banderas de características para controlar el comportamiento.
Prácticas recomendadas: implementar configuración explícita y flags de características, documentar qué variables habilitan cada comportamiento, y asegurarte de que tus entornos de test, staging y producción puedan activar las mismas combinaciones de características para pruebas realistas. Esto aplica tanto a proyectos de software a medida como a plataformas empresariales complejas.
En Q2BSTUDIO, empresa especializada en desarrollo de software y aplicaciones a medida, ayudamos a diseñar arquitecturas y flujos de configuración que evitan estos antipatrón. Si necesitas desarrollo de aplicaciones a medida con buenas prácticas de configuración, o apoyo en migración y despliegue en servicios cloud aws y azure, contamos con equipos expertos en integración, pruebas y seguridad.
Además ofrecemos servicios avanzados en inteligencia artificial, ia para empresas, agentes IA, ciberseguridad y servicios inteligencia de negocio con Power BI para que tus soluciones no solo funcionen correctamente en producción sino que lo hagan de forma segura y escalable. Adoptar banderas de configuración claras mejora la calidad del software a medida, facilita auditorías de ciberseguridad y optimiza despliegues en la nube.
Conclusión clave: deja de usar NODE_ENV para controlar el comportamiento de tu aplicación. Usa flags de características y variables de configuración explícitas. Así tus pruebas validarán lo que realmente ocurre en producción y evitarás el clásico problema de funciona en desarrollo y falla en producción. Antes de escribir if ( process.env.NODE_ENV === production ) pregúntate qué intentas controlar y usa la variable específica para esa configuración.
