Si vous suivez mon blog depuis un certain temps, vous m’avez probablement vu lutter avec la détection d’environnement de Laravel, en particulier en ce qui concerne l’utilisation des variables d’environnement. (Exemple)
Heureusement, Laravel 5.0 simplifie considérablement la détection de l’environnement. Dans 4, vous pouvez avoir plusieurs fichiers d’environnement basés sur le nom de l’environnement (.env.php, .env.local.php, etc.). En toute honnêteté, je n’ai jamais utilisé l’aspect spécifique à l’environnement ; J’imagine que vous pourriez théoriquement l’utiliser pour commettre tous de vos fichiers d’environnement dans votre référentiel. Mais puisque nous ne nous engageons pas n’importe quel de nos dossiers d’environnement, c’était une distinction inutile…et il a forcé le chargement retardé du fichier d’environnement, car il n’a pas pu être chargé avant après l’environnement a été détecté.
Présentation de PHP dotenv
Eh bien, PAS PLUS. Laravel 5.0 utilise PHP dotenv, une bibliothèque tierce éprouvée qui se charge à partir d’un seul .env déposer.
Chaque application Laravel est désormais livrée avec une valeur par défaut .env.example fichier, qui pour le moment ressemble à ceci :
APP_ENV=local
APP_KEY=SomeRandomString
DB_USERNAME=homestead
DB_PASSWORD=homestead
Pour utiliser ce fichier, il suffit de le copier et de nommer la copie .env. Pourquoi ne renommons-nous pas l’original ? Vous verrez dans une seconde.
Maintenant, vous pouvez modifier votre APP_ENV–qui, comme vous pouvez le constater à partir de la valeur par défaut, est le principal moyen pour nous de définir le nom de l’environnement d’application. Découvrez la détection d’environnement plus récente et plus simple dans bootstrap/environment.php:
$env = $app->detectEnvironment(function()
{
return getenv('APP_ENV') ?: 'production';
});
C’est une belle chose !
Personnalisation du fichier d’exemple
Alors, pourquoi copions-nous le .env.example au lieu de simplement le renommer ? Eh bien, imaginez votre application une seconde. Imaginez qu’il ait un besoin constant de définir 10 variables d’environnement. Bien sûr, vous aurez des solutions de rechange raisonnables si elles ne sont pas définies, mais c’est toujours une meilleure affaire si vous les avez toutes.
Où allez-vous stocker les directions pour quelles variables chaque application .env le fichier doit définir ? Vous pouvez le stocker dans le fichier readme, bien sûr… ou vous pouvez simplement mettre à jour le .env.example dossier pour être le instructions pour quelles variables chaque installation de votre application doit avoir.
C’est ça! Besoin de 10 variables pour chaque installation ? Ajoutez ces 10 variables à votre .env.example fichier avec des valeurs par défaut sensibles (ou idiotes). Ce fichier sera engagez-vous dans votre contrôle de source, puis chaque nouvelle installation peut commencer par exécuter cp .env.example .env puis personnalisation .env.
Référencement des variables précédentes
Vous pouvez en savoir plus dans la documentation PHP dotenv, mais voici une note intelligente : vous pouvez référencer des variables d’environnement dans des variables d’environnement ultérieures. Découvrez cet exemple de leur fichier readme :
BASE_DIR=/var/webroot/project-root
CACHE_DIR=$BASE_DIR/cache
LOG_DIR=$BASE_DIR/logs
C’est malin.
Variables requises
Que faire si vous voulez vous assurer que toutes les variables requises sont définies à l’avantplutôt que d’attendre que l’application s’arrête lorsqu’elle y accède ?
Dotenv::required('DB_USERNAME');
// or
Dotenv::required(['DB_HOST', 'DB_NAME', 'DB_USERNAME', 'DB_PASSWORD']);
Fait. S’il n’est pas défini, il lancera un RuntimeException.
Conchl
Simple, facile, puissant. Et cela invalidera complètement tous mes articles de blog, solutions de contournement et plaintes concernant la détection d’environnement dans Laravel. Désormais, il est simple de définir le nom de votre environnement et vos variables d’environnement d’une manière unique, cohérente et prévisible.