minus field
again, all settings things --> plugin configuration. there should be a prexisting PluginConfigurationInterface in core
same as above and same for all code related to core field formatters
should be just summary() when it's not related to settings. see naming of ContextAwarePluginBase
the base class hould not assume field formatters. not every CE formatters wants to use field formatters. we can have 2nd base class fieldformmaterbase or so if that is helpful though
yes, unless there is a reason not to. imho we should use plugin configuration (see https://api.drupal.org/api/drupal/core%21tests%21Drupal%21Tests%21Core%21Plugin%21DefaultSingleLazyPluginCollectionTest.php/function/ConfigurablePlugin%3A%3AdefaultConfiguration/10) for plugin configuration
yes, can we?
Never use abbreviation CE in labels please
use that interface. I think I was posting also something about it in the issue
Wolfgang Ziegler (fd8e4512) at 26 Mar 14:13
Issue #3431256 by junkuncz: Fix phpstan issues in 3.x CI build.
shuld be in setup method?
Wolfgang Ziegler (78f232ed) at 19 Mar 11:40
Issue #3427892 by junkuncz: Stabilise 2.x CI build by addressing ph...
Closes #3427892
this is potentially a BC break. I don't think it makes sense to change this for the stable 2.x branch for no reason. We should configure the testing pipeline for 2.x to match the current code as good as possible and keep it stable instead. small fixes we can do of course, but let's focus on changes in 3.x
Wolfgang Ziegler (1416123c) at 14 Mar 14:44
git commit -m 'Issue #3427333 by junkuncz: Add the Gitlab test runner'
Closes #3427333
added some comments
is this related to make the pipeline green?
the class is supposed to be a data-model, so I think it's fine in that case to exceptionally call out to \drupal - like in module code. can we simply add something like phpstan-ignore-next-line? that#s much better than a broken DI via __construct.