Re-add fixed APP_SECRET value

[nicolas-grekas]

Instead of #1577?

[javiereguiluz]

If I'm right, the only scenario where this wouldn't work is when running Composer with the --no-scripts option. But, as you said on #1577 (comment), this is probably too much. We can skip that use case and it will be fine for 99% of folks.

I'd say this is the solution we were looking for 👍 Thanks!

[rosier]

This could overwrite existing config if a user already created or edited their own .env.local file. Shouldn't we account for that?

That's why I opted for only generating a APP_SECRET on new installs.

[nicolas-grekas]

I don't think this applies: the command is run first. There will be no .env.local to override.

generating a APP_SECRET on new installs

I think that's exactly what this achieves, with support for git-cloned demo apps also.

[lyrixx]

I agree with @rosier

1. I install the project
2. I configure SYMFONY_IDE to enhance my DX
3. I run composer up to try new symfony feature
4. I have lost my SYMFONY_IDE env var

[nicolas-grekas]

I install the project

then done, the command will have created the .env.local file and won't touch it again

[stof]

that's not true. auto-scripts are run each time you run composer update or composer install.

And renaming the file instead of copying it will be a mess for contributors, as it means the git working directory is in a dirty state.

[nicolas-grekas]

Once .env.local.demo is renamed, the second run will do nothing so I'm not sure what's not true?

About the git state, that's right. I don't think this is a blocker, especially as we tried many alternatives and this looks like the most effective in a oneliner.

On the flip side, the git diff will give users an opportunity to read about the concern.

[yceruto]

what about adding it in the post-install-cmd section only?