6

I have a module with a few helpful services and field formatters. I have one field formatter that applies only to entity_reference_revisions fields and, as a result, "uses" and "extends" the Drupal\entity_reference_revisions\Plugin\Field\FieldFormatter\EntityReferenceRevisionsEntityFormatter. However this class may not even be in the codebase at all.

I do not want my module to depend on entity_reference_revisions, but I also don't want to create a submodule just for this one formatter unless I am "required" to do so.

I noticed that when I install my module on a site without entity_reference_revisions present, there are no issues, everything works fine without error. It seems to me that the plugin class is never being loaded so there's no PHP error about a missing class. (My guess is that because the annotation specifies that the field formatter only applies to the entity_reference_revisions field type, which does not exist, then Drupal refrains from loading the class.)

My feeling is that maybe this is not really any different than this formatter being in a submodule that depends on entity_reference_revisions, but I'd like a more objective answer. I checked the PHP coding standards, but I did not find anything definitive. I also noticed, Which modules should be listed as dependency of my module?, but found no definitive answer there either.

What is the Drupal standard in this case? If my module provides a plugin that extends a plugin in some other Module A, is it required (e.g. by coding standards or best practice standards) that my module also depend on Module A?

Improve this question
1
  • 2
    As a side note, the Drupal coding standards do not say anything about how to declare a module's dependencies because that is out-of-scope for the Drupal coding standards, in the same way they do not say anything about which Drupal core classes can be used as parent class.
    – avpaderno ♦
    Commented Sep 15 at 5:58

1 Answer 1

Reset to default
5

For dependencies listed in mymodule.info.yml, I don't think you need to declare the dependency because it's not actually depending on entity_reference_revisions to use your module; the extended class is only made available if entity_reference_revisions is installed.

However, if this is a contrib module and you are using the GitLab CI template to run automated tests, you do need to declare entity_reference_revisions as a dependency in composer.json. This is because the CI template runs phpstan, which needs to parse all classes to check for errors. phpstan can only parse code listed in composer.json, so if you extend a class of a module that is not in composer.json, the test will fail every time.

Improve this answer
3
  • 2
    I agree: Drupal does not throw exceptions for a field formatter that is defined for a non-existing field type; it will just never use that field formatter or propose it as option for a field. That is different in the case of GitLab Ci jobs like phpstan and phpunit, which need the other module to run without failures.
    – avpaderno ♦
    Commented Sep 15 at 6:06
  • In this case, where would be needed for these CI jobs, would it be recommended to add entity_reference_revisions in the require or require-dev section of my composer.json file?
    – sonfd
    Commented Sep 15 at 11:43
  • 1
    @sonfd For phpstan they can be in either, so I would use require-dev. You can also add the module (a second time) as a suggest with a brief note explaining what you can do if you use the two modules together. For an example, see this composer.json: git.drupalcode.org/project/decoupled_json_log/-/blob/1.0.x/… jsonrpc is not a dependency of the module in module.info.yml, but the module contains some plugins for jsonrpc, so it is a dev dependency for phpstan and also suggested.
    – Patrick Kenny
    Commented Sep 15 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.