The widget form element does not contain the bundle and the entity type

I did a quick test, also reviewed the code. It's a trivial addition to expose more information for later, the only potential question is if there's already a way to grab this info, if not, it should be fine.

hook_field_widget_form_alter() has access to the widget plugin instance, which in turn would let you get the field definition via $context['widget']->fieldDefinition()

    if ($element) {
      // Allow modules to alter the field widget form element.
      $context = array(
        'form' => $form,
        'widget' => $this,
        'items' => $items,
        'delta' => $delta,
        'default' => $this->isDefaultValueWidget($form_state),
      );
      \Drupal::moduleHandler()->alter(array('field_widget_form', 'field_widget_' . $this->getPluginId() . '_form'), $element, $form_state, $context);
    }

Can you explain why that isn't enough?

If it isn't, could use test coverage I think.

I may be missing something, but when I started looking into #5 as an alternative approach, I don't think the protected WidgetBase::$fieldDefinition property is available (no getter method). There is a protected method to access to the field settings via WidgetBase::getFieldSettings(), but even if that were a public method it wouldn't be usable since the method isn't part of any interface.

OK that's a good point that $this->fieldDefinition isn't available - but why not add public function getFieldDefinition() to WidgetFormBase() then?

add public function getFieldDefinition() to WidgetFormBase()

That would probably be the most flexible solution here.

So every module that needs these data needs to implement this alter and add the information into the element?

But if there are more than one module doing this in the system that seems to not be very efficient.

Is there a good reason why we would not add this basic information into the element by default like in the patch?

So every module that needs these data needs to implement this alter and add the information into the element?

That's a good point. I don't see the harm in adding these details, but we'll still need a test.

Also, while we could make a public method getFieldDefinition() to WidgetBase, it wouldn't be part of any sort of interface, so contrib modules that relied on its usage could only do so for widgets that extend that class.

@mr.york "Reviewed & tested by the community" means that the fix has been reviewed and tested by someone other than the patch author.

Just did a review, the code itself is fine, I have just a general feeling that the Widget-related things would deserve a separate test class, we modify Field\WidgetBase, and test it in field\Kernel\FieldAttachOtherTest , when for example there's field\Kernel\WidgetPluginManagerTest (sure, this does not belong there), but i think this is out of scope here, as this test already tests things related to widgets.

+1

This is blocking #2117827: "None" showing up as an option in multiselect. in the chosen module.

I don't think this is really a feature - just a task - and it is blocking contrib. Given it's BC I wonder whether we should consider for 8.1.1?

Also no one has given a good response to why #8 is not the way to go?

I thought #11 was a good reason, seeing that this patch only adds 2 lines, that probably should be available anyways without having to do all sorts of workarounds to get the data.
Of course that function could be available as described in #8 but then maybe it could be done in a separate issue, and could be used for some other more complex requirement.

Also no one has given a good response to why #8 is not the way to go?

I agree #11 is a pretty good reason. Also, I mentioned that a method on a base class could not be relied on the same way as an interface class in #12. Contrib could only get information on widgets directly extending from the base class, but if a widget didn't use that base class, the method would not reliably be there.

Could we add the method to WidgetBase and WidgetInterface in a point release, or is that considered an API change?

This looks to me like a reasonable solution and unless I'm missing something the pattern is something we use elsewhere (unfortunately) when we're not dealing with real objects. In this case a render array. Often it's hard to determine context and from what I'm seeing this is contextual information that is probably useful in many cases. I think the hypothetical OO render API would be helpful here if we wanted to keep it cleaner. Luckily the amount of data is quite small here so I don't think it's too concerning.

So I think it would be possible to add getFieldDefinition to WidgetBaseInterface in 8.2.x - in fact that interface has the following documentation:

 * This interface details base wrapping methods that most widget implementations
 * will want to directly inherit from Drupal\Core\Field\WidgetBase. See
 * Drupal\Core\Field\WidgetInterface for methods that will more likely be
 * overridden in actual widget implementations.

Which seems pretty analogous to what we want to do here. If someone can point to a widget in the wild not extending WidgetBase then we can explored the solution in #15. That solution is problematic because what happens when we want to do add the next thing from the field definition to the render element.

After discussing this more with @catch, I think we should try to avoid less #random in render arrays - see #2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering) for why. Yes this is a long way off - but we have a better way available here and one that means everything from the field definition is available - not just what we in core deem necessary.

I'm going to work on the interface change.

I went to add this method to the interface, but then when looking into tests, I found this in the field_test_field_widget_form_alter() implementation:

  $field_definition = $context['items']->getFieldDefinition();

Looking into WidgetBase::formSingleElement(), the $context['items'] implements FieldItemListInterface, which definitely has access to the field definition.

So, this may be works as designed?

Closing out.