Use ->loadEnv() instead of ->load() to support the 'standard' Symfony…

[simongroenewolt]

… way of loading .env files. This means .env. for environment specific overrides (e.g. .env.prod) and .env.local and .env..local to make local changes (keep your .local files out of version control)

See #1973

[simongroenewolt]

Hmm, hold on - Is Bolt currently set up to ignore the .env if APP_ENV is set from somewhere else? In that case my proposed change might be slightly confusing / need more work.

[toofff]

Why is this change found in bolt/core?

Bolt/core should be a component, it is found in dependency of a symfony project for example.

So this kind of change should not exist here, because it is related to the project (see bolt/project#31, I have already made a change) and not to the component.

And I think you are adding a maintenance overhead for the core for nothing

[simongroenewolt]

@toofff ah, I forgot about bolt/project when working on this. The 'problem' is that developers on bolt/core itself are using the scripts that are in this repository (I do). I'd say as long as the files I made the change to are in bolt/core, this change makes sense here. You are correct that for end-users the change should be made to https://github.com/bolt/project .

Ideally these scripts should not be duplicated between the two repositories, but I don't know how that would be handled.

Good work on bolt/project/pull/31! I see you're using bootEnv() instead of loadEnv() to include even more fallbacks.

[bobdenotter]

I think this PR looks good! And indeed, some of these changes overlap in bolt/project.

The usecase is slightly different as well: bolt/core is used to work on bolt, and changes in here affect people who have it checked out directly.

bolt/project is used once, during composer create-project, so changes can be made without affecting existing projects.

I have not yet merged @toofff 's PR for 'project', because i need to verify it won't break for people who don't use Docker. :-)

@simongroenewolt Do you want to update this PR to use bootEnv instead? If so, i think we should merge in this one, then @toofff 's one on 'project'. In my opinion it makes sense to do it in that order, because from core to project is "downstream". Then we can test it in project, and if it's good, I can tag a new release of that.

Do the two of you think that makes sense?

[toofff]

@bobdenotter I find that to make sense. 👍

For my PR on the project, for me it is finished because the container "node" is only necessary for the development of "bolt/assets", so no interest in having it here. (I will answer in this way in the other PR)

[simongroenewolt]

@bobdenotter updated to use bootEnv()

FYI: bootEnv() picks up the .env.local.php file if it exists, that you can generate with composer dump-env prod if you need or care about performance. I think this means the check if (! isset($_SERVER['APP_ENV'])) { in console and index.php is outdated. I don't think this PR should be used to make such a drastic change, so I've left it like it is now.

[bobdenotter]

I don't think this PR should be used to make such a drastic change, so I've left it like it is now.

Agreed. Let's make changes like these gradually. I'm going to merge this in to the feature/dotenv-additions branch. That way we can test it properly, in order to include it in the 4.2 release!