Malditos .env

Cuando trabajas en proyectos de Vapor, backend en Swift o cualquier entorno que utilice archivos de configuración tipo .env, puedes encontrarte con un problema bastante molesto en Xcode: estos archivos no se muestran. Ya puedes hacer todos los trucos que quieras que siempre hay que recorrer a la opción de mostrar la carpeta raíz en Finder, mostrar archivos ocultos (Cmd+Shift+.) y entonces sí poder editar tu archivito .env. Esto es bastante tedioso, más cuando estás constantemente cambiando variables, ya sea URLs u otras constantes… pero no temáis he encontrado una solución rápida y sencilla:

Hacer visible el contenido real en un archivo sin punto inicial y luego crear un enlace simbólico para que la aplicación siga leyendo el .env original. Pero vayamos por partes…

Qué es un archivo .env

Un archivo .env es un archivo de texto que se utiliza para definir variables de entorno. Es una forma muy habitual de separar la configuración sensible o dependiente del entorno del código fuente. Estos archivos suelen estar escondidos por defecto y normalmente los sistemas de repositorios ya los ignoran de base, así no corremos riesgo de subir a git datos confidenciales ya que dentro de un .env es normal encontrar valores como:

Credenciales de base de datos
Puertos del servidor
URLs de desarrollo
Claves de APIs
Configuración de Redis
Datos de servicios como APNS u observabilidad

Un ejemplo típico sería:

DATABASE_HOSTNAME="localhost"
DATABASE_PORT="8889"
SERVER_PORT="8080"
DATABASE_USER="root"
DATABASE_PASSWORD="1234"

Esto permite que el proyecto cambie de comportamiento según el entorno sin tener que tocar el código. De esta manera puedo hacer un deployment de del servidor y que funcione en base a los datos de configuración almacenados en el archivo .env del servidor, separando las capas de desarrollo local y la configuración en producción sin tener que preocuparme por subir una versión con configuración errónea y evitando subir esos datos a un repositorio que podría ser compartido con otras personas.

Por qué Xcode da problemas con los .env

Los archivos que empiezan por punto (.) son archivos “ocultos” en entornos Unix-like. Aunque MacOS los soporta perfectamente, Xcode no los gestiona bien como archivos editables y son invisibles al proyecto.

En la práctica, esto es un rollo como hemos mencionado:

El archivo no se previsualiza correctamente
Cuesta abrirlo desde el navegador del proyecto (hay que ir al Finder y mostrar ocultos)

En cambio, si usamos un archivo visible, por ejemplo env.development.sh, Xcode lo abre y edita sin problema. Después basta con enlazarlo mediante symlink al .env.development.sh real que leerá la app.

La idea de la solución

La solución consiste en esto:

Renombrar el archivo oculto .env.development a un archivo visible.
Crear un enlace simbólico con el nombre original .env.development.
Editar siempre el archivo visible desde Xcode.
Dejar que el proyecto siga usando .env.development como hasta ahora.

De esta forma:

Xcode edita el archivo visible
Nuestra aplicación sigue leyendo el .env esperado
No tenemos que cambiar la configuración del proyecto

Si tenías un archivo .env

Este proceso transforma el .env en un archivo visible y crea un enlace simbólico con el nombre original:

mv .env.development env.development.sh 
ln -s env.development.sh .env.development

Qué conviene añadir al .gitignore

Como el archivo visible contiene la configuración real, lo normal es ignorarlo en Git:

env.development.sh

Así evitas subir configuraciones locales o datos sensibles al repositorio.

Crear un archivo base con variables típicas

Si quieres dejarlo preparado desde cero, puedes generar un archivo base con algunas variables habituales y luego crear el symlink automáticamente:

cat > env.development.sh <<'EOF'
# Database
DATABASE_HOSTNAME="localhost"
DATABASE_PORT="8889"
DATABASE_USERNAME="root"
DATABASE_PASSWORD="root"
DATABASE_NAME="<DATABASENAME>"

# Server
SERVER_HOSTNAME="localhost"
SERVER_PORT="8080"# Paths
EOFrm -f .env.development
ln -s env.development.sh .env.development

Por qué usar .sh y no .txt

Aquí hay un detalle interesante. El archivo sigue siendo simplemente texto, pero usar extensión .sh tiene la ventaja de que directamente le aplica la sintaxis Bash y nos aparecerá claramente coloreado los textos entrecomillados de color rojo, de lo contrario, si usáramos por ejemplo txt, no habría sintaxis y la deberíamos cambiar para verla bien. Que no pasaría nada, pero es que Xcode no se queda con la copla y hay que cambiarlo cada vez que abrimos el archivo (¡damn!)No es que ese archivo vaya a ejecutarse como script necesariamente, pero para edición dentro de Xcode suele ser más cómodo.

Ventajas de este enfoque

Este método tiene varias ventajas:

No obliga a cambiar cómo se carga el .env
Mantiene compatibilidad con el proyecto actual
Facilita editar el contenido desde Xcode
Evita pelearte con archivos ocultos dentro del IDE
Es rápido de aplicar en cualquier proyecto local

Cosas a tener en cuenta

Hay un punto importante: el symlink debe conservar el nombre exacto del .env que espera tu aplicación. Si tu proyecto carga .env.development, el enlace debe llamarse exactamente así.

Además, si trabajas en equipo, conviene dejar claro:

Qué archivo se ignora en Git
Si el symlink también se versiona o no (normalmente ya están desactivados los .env)
Cuál es el archivo plantilla base para nuevos desarrolladores

Conclusión

Los .env son una pieza muy habitual en proyectos modernos, pero Xcode no siempre ofrece la mejor experiencia al editarlos directamente. Convertir el contenido real en un archivo visible y enlazarlo con un symlink al .env original es una solución simple, limpia y muy efectiva.