This is to avoid conflicting with the z-index of the search input.

I think in a follow up PR we should add a "hover container" to the end of the document, give that element z-index: 1 and portal all hover-like elements (tooltips, popovers, etc) into that container.
We are already portalling them to the end of the document but because the search input needs a higher z-index it will still be rendered on top of them.

Moved the bottom border to the Tabs component so the TabsHeader component can be used separately.

I added this function because I couldn't get the existing ones to do what I wanted. overflow isn't enough because I need more than a "small" and "large" state, and computeFit doesn't work in this case because the list of elements is not statically known. I think this is strictly more general than both of those with the tradeoff that changes need to be committed to the DOM with tick before we can re-measure, which I think means there is a possibility of flashing. I was unable to observe any flashing though, so maybe there is another layer of batching happening somewhere.

Anyways, this is probably the piece that could use the closest review

This seems fine to me, especially since it avoids the limitations of computeFit, though I don't understand

computeFit doesn't work in this case because the list of elements is not statically known.

It seems you are essentially doing the same as before. Why is the list of elements (the menu entries) not statically known?

"statically known" was a lazy reason. In reality, it was mostly an issue with TabsHeader having its own wrapper, so we would need to add functionality to TabsHeader to apply the action. I got this mostly working, but it would not work more generally, such as if we have two different elements that can shrink (like in the file header where both the file name and the actions will be shrinkable). So it's a bit forward-looking as well as not wanting to expand the TabsHeader interface.

This seems fine to me, especially since it avoids the limitations of computeFit, though I don't understand

computeFit doesn't work in this case because the list of elements is not statically known.

It seems you are essentially doing the same as before. Why is the list of elements (the menu entries) not statically known?

I think in a follow up PR we should add a "hover container" to the end of the document, give that element z-index: 1 and portal all hover-like elements (tooltips, popovers, etc) into that container.
We are already portalling them to the end of the document but because the search input needs a higher z-index it will still be rendered on top of them.