ConfigFormBase::typedConfigManager() should have been removed when deprecations were removed in 11.0

Deprecation code was added in https://www.drupal.org/project/drupal/issues/3394197 🐛 [regression] The new property \Drupal\Core\Form\ConfigFormBase::$typedConfigManager conflicts with some contrib modules Fixed and later it was removed in https://www.drupal.org/project/drupal/issues/3443488 📌 Remove deprecated code from lib/Flood and lib/Form Fixed

Was just checking the code in the ConfigFormBase class and was wondering if it's safe to fully remove the method?

/**
   * Returns the typed config manager service.
   *
   * @return \Drupal\Core\Config\TypedConfigManagerInterface
   *   The typed config manager service.
   */
  protected function typedConfigManager(): TypedConfigManagerInterface {
    if ($this->typedConfigManager instanceof TypedConfigManagerInterface) {
      return $this->typedConfigManager;
    }
    return \Drupal::service('config.typed');
  }

Would it be safer to keep to just remove the condition and turn it into a getter to avoid breaking contrib or custom modules that could be using it? Like so:

/**
   * Returns the typed config manager service.
   *
   * @return \Drupal\Core\Config\TypedConfigManagerInterface
   *   The typed config manager service.
   */
  protected function typedConfigManager(): TypedConfigManagerInterface {
    return $this->typedConfigManager;
  }

Just want to make sure!

It would be safer to keep the method and just remove the condition, turning it into a getter. This way, you avoid the risk of breaking contrib or custom modules that might rely on it. By keeping it as a getter, you ensure backward compatibility.

/**
 * Returns the typed config manager service.
 *
 * @return \Drupal\Core\Config\TypedConfigManagerInterface
 *   The typed config manager service.
 */
protected function typedConfigManager(): TypedConfigManagerInterface {
  return $this->typedConfigManager;
}

This will make sure your modules continue to work seamlessly without any unexpected breaks. Does this give you a bit more confidence in your change?

The typedConfigManager() was only added for deprecation handling, when the TypedConfigManager was added to the constructor.

There's no need for it to exist in the long term.

Fix looks good, pipeline needs to re-queue failed job

I thought faux commit would do the magic after learning about composer 2.8.1 issues failing tests.
Tests are still failing which is quite unfamiliar to me

Time: 00:08.303, Memory: 8.00 MB
    
    There was 1 error:
    
    1)
    Drupal\Tests\Composer\Plugin\Scaffold\Functional\ComposerHookTest::testComposerHooks
    RuntimeException: Exit code: 1
    
    Creating a "fixtures/drupal-drupal" project at "./create-project-test"
    Installing fixtures/drupal-drupal (1.0.0)

Any idea? @andypost

Now pipelines are passing ~~ seems some issue with gitlab CI or seems failing due to composer 2.8.1(Not sure)
Moving into review

If it was missed in D11 that was definitely a mistake but think it should be deprecated properly since D11 is already out.

Leaving novice tag.