Symfony 6.3 BC break

[mihai-stancu]

Hello,

Symfony appears to have changed various things so that Clockwork does not work out of the box.

First thing I ran into was that stricter types are now required for the getContainerExtensionClass method:

ClockworkBundle::getContainerExtensionClass(): string

The next issue was not receiving the $container injected in ClockworkFactory -- this may relate to my setup, I'll test on a vanilla symfony install to make sure.

What is your currently supported version of Symfony?

[mihai-stancu]

At the least this should be mentioned in composer's conflicts section to avoid installing clockwork on an usupported version of Symfony.

[erikn69]

Symfony 6 compatibility was reversed, 51eae8d

[mihai-stancu]

Thank you @erikn69 that's useful to know.

[erikn69]

There are also PHP 8.2 deprecations ,

clockwork/Clockwork/Support/Symfony/ClockworkFactory.php

Line 12 in e46932c

$this->container = $container;

Dynamic propertiy `container`
User Deprecated: Since symfony/framework-bundle 5.4: 
    Accessing the "profiler" service directly from the container is deprecated, use dependency injection instead.

[itsgoingd]

Hey, I've pushed a bunch of Symfony 6 fixes to dev-master, please give it a try and let me know if it works for you.

Unfortunately, it's impossible to release these in 5.1.x, as they break compatibility with older Symfony versions running on older PHP.

[mihai-stancu]

Thank you, I'll take it for a spin!

[PaolaRuby]

@itsgoingd hi, what about two Symfony/ClockworkBundle.php files, one for V6 support, like

// Symfony/ClockworkBundleV6.php
class ClockworkBundleV6 extends Bundle
{
	protected function getContainerExtensionClass(): string
	{
		return ClockworkExtension::class;
	}
}

[itsgoingd]

@PaolaRuby That's definitively possible, I'm just not fan of that naming convention and I'm working on a next major version of Clockwork anyway. Since major versions can break backwards-compatibility, we can replace the main Symfony bundle with the updated one and either provide another legacy one or tell people using older Symfony to use older Clockwork version.

[edvordo]

Old-ish issue, but I thought I'd chime in anyway.

Instead of two files, I've seen devs, that wanted to support older applications just do a PHP version conditional in the class file and implement the whole class within that conditional.

In this case, it could look something like this:

if (true === version_compare(PHP_VERSION, '7.0.0', '<')) {
  class ClockworkBundle extends Bundle
  {
	  protected function getContainerExtensionClass()
	  {
		  return ClockworkExtension::class;
	  }
  }
} else {
  class ClockworkBundle extends Bundle
  {
	  protected function getContainerExtensionClass(): string
	  {
		  return ClockworkExtension::class;
	  }
  }
}

Ugly? Maybe, but it's a solution.

[itsgoingd]

This would be a valid option if the Symfony versions differed only in apis, but won't work when one of the versions uses new PHP syntax features. The older PHP parser needs to parse both branches and throws an error once it encounters the new return type syntax.

[edvordo]

Well, the symfony kernel provides its current version, so the above conditional could be changed to something like this

if (true === version_compare(\Symfony\Component\HttpKernel\Kernel::VERSION, '6.0.0', '<')) {

and you'd be good to go for whichever version of symfony the end-project uses.

Granted, this is just one class, relatively small and easy to maintain. I'm not familiar with symfony or clockwork enough to say how many classes would need a workaround like this or how much more headache it would add to your life.