Readd the APP_SECRET value

[javiereguiluz]

Context:

• The promise of the "Symfony Demo" app since day one is that it works out of the box. You clone the repo or create an app based on it using Composer ... and it just works. You don't have to run any command, change any config or do anything at all. It just works.
• "Symfony Demo" is a very important application also outside the Symfony context. Folks working on PHP source code routinely use it to benchmark changes in PHP.

As explained in #1574, we're not fulfilling that promise right now because of the change made in #1532. So, let's fix that. The change proposed in #1574 is correct ... but it could be not enough. If you run Composer with the --no-scripts option, the proposed script won't run and the error will happen again.

So, in this PR I propose to go back to what worked before ... and add a message explaining that folks don't need to do that in their apps; this is just for the Symfony Demo. There are other parts of the app where we say "we do this because this is a Demo app and bla bla, don't do this in your own app". So, this should be fine.

[nicolas-grekas]

It should be added to .env.local instead

[javiereguiluz]

I added it to the .env.local, and added another comment explaining that you don't have to commit that file in real Symfony apps. Thanks!

[lyrixx]

Both commiting the secret or the .env.local are wrong but I think commiting the .env.local is more wrong. It prevent us to add the SYMFONY_IDE env var. Yes I can add it but I'll keep a diff every time. Since we add a comment, I think it's fine to add the secret to the .env file

[nicolas-grekas]

My bad, this is added to .env.dev when using recipes, so let's follow this lead instead!

[javiereguiluz]

If I add it to .env.dev, whenever a user sets APP_ENV to prod in .env (a very common scenario for this app when using it in benchmarks, etc.) a 500 error is triggered. 😐

Folks, this is not a normal Symfony app. It's a bit special and its main feature is that it must work under all circumstances and for all users (git clone or composer create-project; using Composer with or without --no-scripts; in dev and prod envs; etc.)

So, is there any alternative to just defining the secret in the main .env file?

[nicolas-grekas]

This is also a showcase of best practices, that's why we should find a better option.

using Composer without --no-scripts

I don't think this is valid objection. If you run without composer scripts, that's your issue.

git clone or composer create-project

That's the issue with #1574 to me: not dealing with git clone.

[javiereguiluz]

Let's close in favor of #1579 which looks like the solution we were looking for. Thanks!