Configurar environments en Angular te permite separar variables y URLs entre desarrollo y producción, evitando que toques datos reales mientras programas. Es una práctica clave para cualquier proyecto que se conecte a una API y necesite proteger su entorno productivo.

¿Qué son los environments en Angular y por qué importan?

Angular maneja por defecto dos ambientes: uno de desarrollo y uno de producción. La diferencia entre ellos define a qué API te conectas, qué llaves usas y qué configuraciones se activan según el contexto en el que se ejecuta tu aplicación.

El problema aparece cuando, sin esta separación, terminas pegándole directamente a la API de producción mientras desarrollas. Imagina que estás probando la función de eliminar productos y borras uno que un usuario real estaba a punto de comprar. Ahí está el riesgo.

¿Para qué sirven los environments en Angular? Sirven para separar configuraciones, URLs y variables sensibles entre ambientes como desarrollo y producción, evitando errores graves al manipular datos reales durante el desarrollo.

¿Cómo habilitar los environments con ng generate environment?

Angular no activa los environments por defecto. Tienes que pedírselo de forma explícita con un comando que los configura automáticamente [02:00].

En la terminal ejecutas:

bash ng generate environment

Esto crea una carpeta nueva con dos archivos:

• environment.ts, que corresponde al ambiente de producción.
• environment.development.ts, que corresponde al ambiente de desarrollo.

Cada archivo arranca con un objeto vacío al que puedes ir sumando llaves como production: true o production: false, y variables propias como una myVar con el valor que necesites.

¿Qué URL debo poner en cada environment?

La configuración más importante suele ser la apiUrl. La recomendación es colocar solo el dominio, sin subpaths ni slash al final, para mantener limpia la base de la conexión [04:30].

• En environment.ts (producción): la URL real de tu API productiva con HTTPS.
• En environment.development.ts: una URL distinta, que puede ser un endpoint específico de desarrollo (algo tipo apidev.api) o un backend corriendo en local con Docker o Node.js, normalmente en localhost:3001.

Así, cuando estás desarrollando, le pegas a un entorno aislado y no afectas datos reales.

¿Cómo usar el archivo environment dentro de un servicio?

Una mala práctica frecuente es dejar la URL quemada directamente en el servicio. La idea es reemplazarla importando el archivo de environment y consumiendo environment.apiUrl desde ahí [07:15].

Lo interesante es cómo Angular hace el switch entre ambientes:

• Cuando ejecutas ng serve, toma automáticamente el archivo environment.development.ts.
• Cuando ejecutas ng build para producción, toma automáticamente environment.ts.

No necesitas configurar nada adicional. Importas siempre el mismo archivo y Angular se encarga de resolver cuál usar según el comando.

¿Cómo cambia Angular entre development y production? Angular detecta el comando que ejecutas: ng serve carga el archivo de desarrollo y ng build carga el de producción, sin configuración manual extra.

¿Cómo verificar que el environment está funcionando?

Al correr ng serve y abrir el proyecto en el puerto 4200, puedes revisar la pestaña Network del navegador. Si configuraste bien el ambiente de desarrollo, las peticiones ya no salen hacia la API de producción, sino hacia tu localhost:3001 o el endpoint de desarrollo que hayas definido [10:20].

Esa verificación rápida te confirma que el switch entre ambientes está operando como debe.

¿Cómo limpiar los imports con short imports en TS config?

Importar el environment con ../../ repetido funciona, pero no es la mejor práctica. Cuando tienes servicios en distintos niveles de carpetas, terminas con cadenas largas y difíciles de leer, e incluso reglas de linter como las de Prettier te marcarán que la línea es demasiado larga.

La solución son los short imports configurados en el tsconfig.json, que funcionan como accesos directos hacia carpetas específicas del proyecto [12:40].

Crear uno para los environments es directo:

1. Abres el tsconfig.json y agregas un alias, por ejemplo @env.
2. Apuntas ese alias a ./src/environments.
3. En tus servicios reemplazas el import largo por import { environment } from '@env/environment'.

El resultado es código más legible, sin puntos encadenados y más fácil de mantener cuando el proyecto crece.

¿Existe un ambiente intermedio entre desarrollo y producción?

Más allá de development y production, en el mundo profesional aparece un tercer ambiente muy usado: el de staging. Es un entorno intermedio, pensado para QA, testing y validaciones previas antes de mover cambios a producción [15:50].

Angular no lo crea por defecto, pero puedes configurarlo manualmente para sumarlo a tu flujo. Cuéntame en los comentarios qué encontraste sobre el ambiente de staging y cómo lo implementarías en tu proyecto.