I do indeed find myself writing this manually into almost every project I write as well. +1

I tought laravel's .env file is designated for a credentials and sensitive information only while the config file is used for a usual needs where you can change app's name and similiar data.

@danieltorscho is correct. You are meant to edit the config files in apps. However, this PR is sent more than once a month, so I suspect is was merged to stop yet more PRs.

@GrahamCampbell @danieltorscho This could be useful when you want to have different title for the staging\dev application for example.

@GrahamCampbell If the .env file was only for credentials and sensitive information, then there are lots of things in the standard .env file that shouldn't be there - the database connection in use, the app URL, debug level, which drivers are being used for broadcast, log, session and queue etc. The .env file should be used for things that change per environment - not just for sensitive information.

This PR isn't about not wanting to edit config files in apps - of course you're supposed to do that for the things that are consistent between every deployment / environment of your app - but there are situations where you want a different app name in different environments to make identification easier. Mailables, for example, use the app name by default, and knowing that I have a contact message from my staging area and not the production server can be quite useful.

If this PR has been sent more than once a month, that's a clear indication that there's a need for this, which I suspect is why it was merged, rather than it being just to stop more PRs of the same nature.

/cc @danieltorscho @a-komarev @m1guelpf @DojoGeekRA

@GrahamCampbell sorry bro, I have to sit with @mdavis1982 on this one.

.env is clearly not only for credentials, it's quite obviously for generic configuration purposes that may differ based on the environment. Keywords here being "generic", "configuration" and "environment". If this file was honestly just for credentials (and the non-credential based default stuff was removed) then the file would likely be called something much different (such as .secrets or something).

As far as examples go for this being an exactly acceptable use-case for APP_NAME, I direct you at one of your (our) favourite project's .env.example file

💓

The file is for environment specific things, by definition. It is not exclusively for credentials, but also for things that vary per environment, such as choosing drivers.

It is not for things that are fixed per application, and is commonly abused for this.

(such as .secrets or something).

I actually think it would be a pretty cool idea to introduce a .secrets file to sit along side .env to avoid that file becoming really full.

@GrahamCampbell that's exactly what I said 😄 However, you did say that @danieltorscho was correct in saying that this file was designated for credentials and sensitive information only, which isn't the case.

This isn't an abuse of the .env file. The application name can have a good reason to change per environment and, therefore, is an ideal candidate to be stored in the environment file.

With regards to the .secrets file - I tend to agree. It would be neat to have credentials in there, but it would mean that some things could get separated from their other options - for example moving DB passwords away from the rest of the DB environment-specific configuration

Separating .env to .env + .secrets will bring only headache in my opinion. It will be harder to maintain it because API endpoints will be located in .env file and API keys will be in .secrets if follow the logic of extracting sensitive data to separate file.
Better leave it as is and use third party packages for such things.

I get all points around, but it's not hard to add env('SOME_VAR', 'default') on any config you want, I just don't think that every possible config option that CAN be changed per environment for everyone's potential use case needs to be in by default.

I don't use DATABASE_* variables, as I use Heroku buildpacks, so I get a DB_HOST variable that I need to split off into their own properties for the database config to work, so does that mean I should submit a PR with that in it, and the boilerplate above config/database.php to do the splitting? Because more people use Heroku and it's buildpacks than people who want to change their app name per environment...

@joshmanders I'm 100% willing to bet that more people change their app name than people use Heroku. That said, no you shouldn't. Don't be pedantic for the simple reason of being pedantic.

@ConnorVG all I am saying is, if you change your app name every 3 minutes, then make the configuration changes yourself. Flooding the .env file with cruft that the majority of people don't use is annoying.