Avoid dynamically defining constraints

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Checking on this, it's still relevant.

The metadata (=field definitions) is missing out on constraints that are defined via \Drupal\Core\Field\FieldItemList::getConstraints(). Some modules and even core use this to define additional constraints, like \Drupal\Core\Field\EntityReferenceFieldItemList::getConstraints. While this code does not make use of the field value, it could, but that's not intended. It would still make sense to improve this API to make sure constraints are defined not dynamically, e.g. by replacing the method with a static one - like \Drupal\Core\Field\FieldItemList::processDefaultValue.

This is of course an API change, so would need BC and communicated deprecation.

While the API change would be happening on typed data level, the impact would be mostly for field type developers. So moving this to entity field api to get some feedback of entity system maintainers.

Proposal:
- Deprecate TypedDataInterface::getConstraints()
- Add "static public function getValidationConstraints(DataDefinitionInterface $definition)"

So that means all the implementations of FieldItem::getConstraints() would have to follow and implement the static getValidationConstraints instead.

So moving into the entity queue for sub-system maintainer review.

I've updated the proposal in the issue summary to reflect this is released now + worked in my proposal from the previous comment.