Obviously, having a single database configuration string is much easier for Flex, but makes it harder / more awkward to reuse the environment variables for other purposes, say injecting them to a MySQL Docker container as the required values are embedded inside a Doctrine-specific connection format.

Obviously, I can ship my own database config which gets the job done, but it means the user will have to specify database settings in .env twice which will get confusing.

The defaults in framework uncomments the session and thus the session service is not being created. But what can one do if a bundle (recipe) needs the session to be available?

| Q | A | ------------- | --- | License | MIT | Doc issue/PR | n/a

Currently, installing doctrine/annotations is needed to be able to use the #[Route()] PHP 8 attribute. It'unfortunate because attributes can work out of the box and this dependency is not needed with PHP 8.

This PR enables "annotation" support (actually attribute support) by default, even if doctrine/annotations isn't installed. This PR targets Symfony 5.3 as it's a new feature. A side effect will be that the default skeleton will not work by default with PHP 7, but IMHO it's not a big issue because most new projects using Symfony 5.3 should use PHP 8. Also, this moves the ecosystem forward.

Why are this the only options:

// Load cached env vars if the .env.local.php file exists
// Run "composer dump-env prod" to create it (requires symfony/flex >=1.2)
if (is_array($env = @include dirname(__DIR__).'/.env.local.php')) {
    $_SERVER += $env;
    $_ENV += $env;
} elseif (!class_exists(Dotenv::class)) {
    throw new RuntimeException('Please run "composer require symfony/dotenv" to load the ".env" files configuring the application.');
} else {
    // load all the .env files
    (new Dotenv())->loadEnv(dirname(__DIR__).'/.env');
}

Why not for example this?

if (!($_SERVER['APP_ENV'] ?? $_ENV['APP_ENV'] ?? null)) {
    if (is_array($env = @include dirname(__DIR__).'/.env.local.php')) {
        $_SERVER += $env;
        $_ENV += $env;
    } elseif (!class_exists(Dotenv::class)) {
        throw new RuntimeException('Please run "composer require symfony/dotenv" to load the ".env" files configuring the application.');
    } else {
        // load all the .env files
        (new Dotenv())->loadEnv(dirname(__DIR__).'/.env');
    }
}

Is there a reason not allowing "native" environment to be used I missed? I know, this is all not optimized for docker, because docker is not the only way of doing things, but:

Docker is not the problem! Docker only makes the design flaw visible. The same applies, when you run without docker on a "user per app" basis and the user has environment set to run the app and there might be some task executed that has to run with the same user and share the environment. The environment is here isolated to the user the app runs on. No collisions at all. Now if you do not have this setup, the above would still work with DotEnv or dumped .env.local.php.

My strategy using docker would be then:

• remove symfony/dotenv
• use .env.local as .env before the flex change
• use .env as .env.dist before the flex change
• instead of "overriding" only some vars from .env in .env.local, have them all defined, like before in .env

This would allow to load native environment als also have a single environment "object". But would also allow the other way of usage you intended for also good reasons.

| Q | A | ------------- | --- | License | MIT

Until now, I've been advocating that peoples' CI should fail whenever a deprecation is reported. But when a vendor throws a deprecation, sometime, it's not your fault and you can't do anything about it (except contributing back to the project, which is good for OSS!)

Talking on Slack, @greg0ire convinced me we can do this change: by setting SYMFONY_DEPRECATIONS_HELPER to 999999 by default, we make ppls' CI green (when they don't raise more than 1M deprecations.) And it still makes the deprecation report visible on the tests' output so that ppl still have some incentive to fix them.

Fixes https://github.com/symfony/symfony/issues/27936

The DATABASE_URL defined in DoctrineBundle recipe (see https://github.com/symfony/recipes/blob/master/doctrine/doctrine-bundle/1.6/manifest.json#L13) uses DSN syntax, that only Doctrine is able to parse.

This results in inability to use same DATABASE_URL, when configuring PdoSessionHandler class to store sessions in the database.

Possible solutions:

1. instead of single DSN settings have separate setting for each database connection property (see https://github.com/symfony/symfony-standard/blob/3.3/app/config/parameters.yml.dist#L5-L9)

pros: no code changes needed to make it work cons: more settings

2. improve PdoSessionHandler to parse Doctrine-specific DSN

pros: PdoSessionHandler works with Doctrine bundle not installed cons: code duplication

3. improve PdoSessionHandler to use Doctrine created connection

pros: you will see DB queries made by PdoSessionHandler in Web Profiler cons: PdoSessionHandler would depend on DoctrineBundle

| Q | A | ------------- | --- | License | MIT

When the console cache:clear command is launched without annotations enabled having this part uncommented (as it was previously in the symfony/routing recipe) cause the command to fail.

Executing script cache:clear [KO]
 [KO]
Script cache:clear returned with error code 1
!!  
!!   // Clearing the cache for the dev environment with debug                       
!!   // true                                                                        
!!  
!!  
!!                                                                                 
!!    [Symfony\Component\Config\Exception\FileLoaderLoadException]                 
!!    Cannot load resource "../src/Controller/". Make sure annotations are enable  
!!    d.                                                                           
!!                                                                                 
!!  
!!  cache:clear [--no-warmup] [--no-optional-warmers] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command>
!!  
!!  

This PR should fixe this. (I don't know how to test with a different recipe repo).

Related to https://github.com/symfony/recipes/pull/491

These two should be equivalent, shouldn't they?

> APP_ENV=prod APP_DEBUG=0 bin/console cache:clear --no-warmup
> bin/console cache:clear --no-warmup --env=prod --no-debug

Reproducer:

> composer create-project symfony/skeleton skeleton 
> cd skeleton
> rm -rf vendor
> composer install --no-dev #error will be here too.
> bin/console cache:clear --no-warmup --env=prod --no-debug

> Fatal error: Uncaught RuntimeException: The "APP_ENV" environment variable is not set to "prod". Please run "composer require symfony/dotenv" to load the ".env" files configuring the application. in project/src/.bootstrap.php on line 13

Thanks

| Q | A | ------------- | --- | License | MIT

fixes

.env: line 48: syntax error near unexpected token `('
.env: line 48: `CORS_ALLOW_ORIGIN=^https?://localhost(:[0-9]+)?$'

with source .env

after

echo $CORS_ALLOW_ORIGIN
^https?://localhost(:[0-9]+)?$

let me know if im missing something :thinking:

| Q | A | ------------- | --- | License | MIT | Doc issue/PR | symfony/symfony-docs#...

@javiereguiluz maybe you know about this? @fabpot otherwise? This looks scary for now :)

It was proposed back in 2019 by @javiereguiluz, but for some reason didn't get enough popularity. Though, now Symfony's documentation mentions this improvement in a "Set-up your Test Environment" paragraph:

It is recommended to run your test with debug set to false on your CI server, as it significantly improves test performance. This disables clearing the cache. If your tests don't run in a clean environment each time, you have to manually clear it using for instance this code in tests/bootstrap.php:

// ...

// ensure a fresh cache when debug mode is disabled
(new \Symfony\Component\Filesystem\Filesystem())->remove(__DIR__.'/../var/cache/test');

We can live with this "inconvenience", especially with the benefit it gets (example for my project):

- Time: 04:13.959, Memory: 547.01 MB
+ Time: 02:45.307, Memory: 473.00 MB

what do you think to update an official recipe and add the following line to phpunit.xml.dist somewhere here:

https://github.com/symfony/recipes/blob/a624d3bf1def68bbd2d542b3a99216c0af090552/symfony/phpunit-bridge/5.3/phpunit.xml.dist#L14

+ <server name="APP_DEBUG" value="false" />

This will help many developers creating new projects to not waste time with functional tests.

Related to:

• https://github.com/symfony/recipes/issues/1024
• https://github.com/api-platform/api-platform/pull/2078

| Q | A | ------------- | --- | License | MIT | Doc issue/PR | -

Needs https://github.com/doctrine/DoctrineBundle/pull/1568 and https://github.com/doctrine/orm/pull/10187

| Q | A | ------------- | --- | License | MIT | Doc issue/PR | symfony/symfony-docs#...

Replace schickling/mailcatcher Docker image with jeanberu/mailcatcher because it is smaller with less MB. Functionality should be the same.

schickling/mailcatcher: Compressed size: 25.44 MB https://github.com/schickling/dockerfiles/blob/master/mailcatcher/Dockerfile

jeanberu/mailcatcher: Compressed size: 15.27 MB https://github.com/Jean-Beru/docker-mailcatcher/blob/master/Dockerfile

This should save some MBs on the internets.

Installation on Symfony 6.1 (flex) with PHP 8.0 not publishing the bundle/ (assets) and api_platform.yaml too. Why?

I install it with: composer req api

I get the warning that the file does not exists docker-composeyml. (Missing .). Mac M1. The file docker-compose.yml does exist in my project. As it is correct in https://github.com/symfony/recipes/blob/b3395a2477b6d58089f92ef3a0d2e58226825a3a/doctrine/doctrine-bundle/2.4/manifest.json it is maybe a problem of the system itself?

`composer recipes:update doctrine/doctrine-bundle Updating recipe for doctrine/doctrine-bundle...

Yes! Recipe updated!

The recipe was updated but with one or more conflicts. Run git status to see them. After resolving, commit your changes like normal.

NOTE: The file docker-composeyml was not updated because it doesn't exist in your app.

Would you like to save the "diff" to a file so you can review it? (Y/n) Y

Saved diff to doctrine.doctrine-bundle.updates-for-deleted-files.patch

• [doctrine-bundle] Upgrade to Postgres 14 and MySQL 8 (PR https://github.com/symfony/recipes/pull/1115) `

P.S. The post-install notice should be updated to postgres 14 as well. https://github.com/symfony/recipes/blob/b3395a2477b6d58089f92ef3a0d2e58226825a3a/doctrine/doctrine-bundle/2.4/post-install.txt

Maybe this Line too. https://github.com/symfony/recipes/blob/main/doctrine/doctrine-bundle/2.4/config/packages/doctrine.yaml#L7