Make it possible to disable `config/reference.php`

[ruudk]

Description

Generating this file takes time, and in our setup we like to keep things as fast as possible (since compiling the cache is already quite slow, on a large project with 15k classes).

It would be great if we could turn off this class so that it won't be generated.

Example

No response

[GromNaN]

If you remove the .kernel.bundles_definition parameter, that disables this feature:

symfony/src/Symfony/Bundle/FrameworkBundle/FrameworkBundle.php

Lines 152 to 154 in 55ce127

	if ($container->hasParameter('.kernel.config_dir') && $container->hasParameter('.kernel.bundles_definition')) {
	$container->addCompilerPass(new PhpConfigReferenceDumpPass($container->getParameter('.kernel.config_dir').'/reference.php', $container->getParameter('.kernel.bundles_definition')));
	}

That can be done by overriding Kernel::getKernelParameters:

symfony/src/Symfony/Bundle/FrameworkBundle/Kernel/MicroKernelTrait.php

Line 266 in 55ce127

$parameters['.kernel.bundles_definition'] = $bundlesDefinition;

[VincentLanglet]

Could be interesting to add an option for this (?)

[GromNaN]

Yes, as it's useless when you don't use the PHP config format. It can be named framework.reference_php.
Since it should not change without package update, one can choose to use an env var in this config.

[trsteel88]

Is there an explanation around what config/reference.php is? Should it be in the .gitignore since it keeps changing?

[alexislefebvre]

Is there an explanation around what config/reference.php is?

You can see the PR here: #62129

It helps IDEs to understand the PHP config files.

Should it be in the .gitignore since it keeps changing?

This PR recommends to commit this file.

It was changing but this issue has been fixed:

• Running tests changes config/reference.php #62521

Patches have been published for FrameworkBundle a few hours ago.

[trsteel88]

I mean whenever you run composer update it changes if there are changes in the packages. Seems strange that if this is a file that constantly compiles, why wouldn't it be ignored? It isn't a file anyone would modify?

[philbates35]

On a related note, we're committing the reference.php as recommended, Renovate ran on the repository and updated symfony/ packages to 7.4.1 which caused the reference.php to update, however the Renovate PR obviously doesn't commit that changes to reference.php so when that PR was merged and our engineers pulled in the latest main and ran bin/console cache:clear they're now seeing reference.php modified, so someone had to manually open a PR to sync it.

If reference.php is definitely intended to be committed, then I kinda think it should be accompanied by a console command that validates that reference.php is in sync which we could have run in CI that would have failed, telling us that we need to manually regenerate and push the reference.php to the Renovate PR before merging.

Basically what I'm getting at is something along the lines of how run composer validate in CI which fails any PR when content-hash is outdated with the contents of composer.json.

EDIT: This isn't specific to Renovate of course, if someone opens up a PR on any repository after running composer update but doesn't commit the corresponding changes to reference.php then we want to know about it.

[GromNaN]

You can run git diff --exit-code after running composer install or any app console command to fail if something changed.

You can also use an action like git-auto-commit to automatically commit modified files.

Note that this file is changing now because we are fixing issues in the way it's generated. That should append less after a few versions.

[ruudk]

If the file is solely for IDE purposes, there is no need to commit it. If you checkout latest version of your branch, you have to run composer install anyway, to get the latest dependencies installed. That will trigger a cache:clear which generates the file.

Unless the file is also for PHPStan purposes. In that case, it might make sense to commit it so that it exists on CI.

But the fact that Dependabot/Renovate won't commit this, kind of shows a flaw in the "commit it" recommendation. We have dozens of Dependabot PR's every week.

[trsteel88]

If the file is solely for IDE purposes, there is no need to commit it. If you checkout latest version of your branch, you have to run composer install anyway, to get the latest dependencies installed. That will trigger a cache:clear which generates the file.

That's what I thought

Unless the file is also for PHPStan purposes. In that case, it might make sense to commit it so that it exists on CI.

I'm still not clear on why phpstan would need this. Especially if you've connected it via the container

[ro0NL]

One reason to commit it is to have nice diffs over time with upgrades and give hints about config changes.

[trsteel88]

My main concern is that if someone runs a cache clear without running composer install first (when there are updates on that branch), that file is going to be built incorrectly.

[nicolas-grekas]

I'd be happy to see perf numbers, esp comparing 8.0 to 7.3: in 7.3 we generate config builders, in 8.0 array shapes (and in 7.4 both). I don't think shapes are more costly to generate than builders.
Also, adding an option is increasing complexity for end users, and preventing us from building on the expectation that this file is generally available.
It'd rather figure out a way to NOT add an option. E.g. finding a way to spot if the php file format is in use, and generate when the answer is yes.

[alexislefebvre]

One reason to commit it is to have nice diffs over time with upgrades and give hints about config changes.

Well, in practice it is not that convenient:

If you — or any developer — know these parameters, you may understand the context, but if you have a lot of configuration, you may need more data to identify the changes. I had to unfold the lines before these 3 lines to get the root element of the configuration to get the whole picture — it is http_client.