Timeline for Is it ok for a plugin to extend a class in some other module without declaring the other module as a dependency?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 15 at 14:21 | comment | added | Patrick Kenny |
@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.
|
|
| Sep 15 at 11:43 | comment | added | sonfd | 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? | |
| Sep 15 at 11:40 | vote | accept | sonfd | ||
| Sep 15 at 6:06 | comment | added | avpaderno♦ | 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. | |
| Sep 15 at 3:19 | history | answered | Patrick Kenny | CC BY-SA 4.0 |