#3476 and #3850 highlight different cases where features implemented in the vendored react-datepicker either cause problems (StrictMode warnings, from a third-party lib) or don't match the expectations of EUI consumers (popover service logic differences).

In both instances EUI provides components (EuiFocusTrap, EuiPopover) that would solve the underlying issue while providing a better overall feature experience. The current vendor structure disallows EUI components in ReactDatepicker, and changing dependencies in the vendor fork would cause even further divergence.

It's been discussed that EuiDatePicker could become a component composed of EuiFieldText, EuiPopover, and Calender (from react-datepicker). This would dramatically reduce EUI reliance on react-datepicker but would require a large amount of logic and functionality transfer (e.g., all open/close and moment parsing logic).

Want to open discussion on options to resolve open issues and decided on the future path of packages/react-datepicker/

//cc @chandlerprall

Action items:

• move into src and merge dependencies
• move more logic and functionality into EUI
• pare down unneeded vendor components and dependencies