👍 forRouter::addResource method, I actually faced a similar problem in thehttps://github.com/rollerworks/RouteAutowiringBundle which I solved by registering the resources with each RouteCollectionBuilder.

Being able to do this in at the router service directly is much simpler, more flexible, (and in my case) reduces the method calls for each collection.

why not consider this as a bug fix?

@nicolas-grekas : Mainly because it may require a new feature and it only targets a developer experience enhancement. But the current implementation is fine if we consider it a bug fix and could go to lower branches (the other implementations aren't).

Which other implems?
Anyway, if this applies to lower branches, I'd personally be OK for bug fix.

Other implementations proposed in the PR description, along with@sstok's one (which is the first suggestion in PR description) 😄

But if this one if fine for everyone, let's target 2.7 as a bug fix.

Rebased on 2.7 and PR description updated.
Let's see if everyone agrees.

In your commit, there is asrc/Symfony/Bundle/FrameworkBundle/Tests/Fixtures/Router/var/cache/appContainer.php file that should not be there.

This file is actually required by the test case, in order to not throw onFileResource instantiation from theRouter and the test case itself. It's empty as I don't need more as I only test the resource is added to the route collection. But I could add some content to be more explicit on its purpose? (Or creating it from the test casesetUp if you prefer that)

src/Symfony/Bundle/FrameworkBundle/Tests/Fixtures/Router/var/cache/appContainer.php file removed. Creating the file in tmp dir duringsetUpBeforeClass instead, so it won't fail on upper branches whereFileResource expects the file to exist.

Just wondering: did we try hard enough tonot invalidate when not required? It's not an issue to invalidate often - until DX is affected by the time it takes to recompile everything (routes + container).

I just had a user hit this bug, so happy to see the PR! But I was also wondering the same thing as@nicolas-grekas - it's kind of a shame toalways rebuild the routing cache when the container is rebuilt, just to catch the edge case of someone modifying a parameter only. A more targeted method would be to only clear when the parameters themselves change. But, this PR is really easy because it took advantage of existing functionality (just add the container as a resource, done!).

Would we be interested in only clearing when parameters change? And if so, how could we do that in some simple way? Would we need to suddenly dump some sort of parameters file separately? Could/should the frameworkRouter create its own file (e.g. with parameters in them) and add that as a resource?

A more targeted method would be to only clear when the parameters themselves change. But, this PR is really easy because it took advantage of existing functionality (just add the container as a resource, done!).

Indeed, I wanted to do so, but I didn't know how to achieve it simply...yet.
Do you thinkbf29783 would be a decent solution?

Another one: thePhpDumper could accept a newparameters_file option and:

1. retrieve the list of parameters throughContainer::getParameterBag()->all()
2. compare it to a previously dumped list of parameters if the file exists.
3. dump the parameters file if different, so the file timestamp is only changed when the parameters changed.

Then, the router (or anyone else) can add it as aFileResource.

But maybe I'm missing a more obvious way.

On another hand, I'm not sure rebuilding the routing cache when the container changes would affect that much DX experience in a medium sized application. So whether or not we opt for a new feature to solve this issue more cleverly, should we merge this one to make lower branches benefits from this fix? (depending on the answers, I may open another PR on master, or replace this one)

Actually, I had an idea: inRouter::resolve(), we resolve the%parameters%. Could we somehow get a list of all of the parameters that were resolved (and their values) and create a new type ofResourceInterface class (e.g.ContainerParameterResource) with these inside. We would also then need a new "resource checker" (class that implementsResourceCheckerInterface) that's capable of handling the newContainerParameterResource. It would compare the current parameter+values to the ones cached inContainerParameterResource to see if there are any differences.

This would add 2 new classes... but would fix this bug without ever unnecessarily rebuilding the routing cache.

Indeed, that should do it and allows to track only required parameters.
I've pushed a new commit tomaster...ogizanagi:feature/container_parameters_resource and will submit a new PR on master with tests tomorrow if it matches your expectations.

Or I can replace this one if you do think we should really avoid tracking the whole container on lower branches.

Closing in favor of#21767 :)