We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
https://twitter.com/mpyw/status/1565934652191539200
基本的に定数は使用する名前空間にenumで定期するのが良い。外部ライブラリのアプリ共通の設定値ならconfig、設定値を環境毎に変えたいなら環境変数。それで環境変数の代替手段が.envファイル。
ここの環境変数、大部分のケースは .env じゃなくて compose.override.yaml のほうが適切だと思うんよね、Docker 前提なら。 Docker なしでも動くように…って考えてようやく最後に必要になるが、ここも .envrc のほうが本当は正しい
あるいは Docker の場合も compose.yaml で .envrc 由来の環境変数を吸い上げるのもあり 一番やりたくないのが「Docker 使ってるのにアプケーション起動時にアプリケーション側の処理として .env を読み取る」
compose.yaml の場合たしかデフォルトで同階層の .env を見に行くので、 Laravel のルートにある .env とは別管理されてるやつを見るのであればこれもあり
The text was updated successfully, but these errors were encountered:
No branches or pull requests
https://twitter.com/mpyw/status/1565934652191539200
基本的に定数は使用する名前空間にenumで定期するのが良い。外部ライブラリのアプリ共通の設定値ならconfig、設定値を環境毎に変えたいなら環境変数。それで環境変数の代替手段が.envファイル。
ここの環境変数、大部分のケースは .env じゃなくて compose.override.yaml のほうが適切だと思うんよね、Docker 前提なら。
Docker なしでも動くように…って考えてようやく最後に必要になるが、ここも .envrc のほうが本当は正しい
あるいは Docker の場合も compose.yaml で .envrc 由来の環境変数を吸い上げるのもあり
一番やりたくないのが「Docker 使ってるのにアプケーション起動時にアプリケーション側の処理として .env を読み取る」
compose.yaml の場合たしかデフォルトで同階層の .env を見に行くので、 Laravel のルートにある .env とは別管理されてるやつを見るのであればこれもあり
The text was updated successfully, but these errors were encountered: