Looking good thanks @pachacamac. Glad to see it works with polygon holes as well.

Before it's ready to merge we might need to flesh it out in a couple of areas:

1. Allowing options in line with sister functions like pointToLineDistance. For example, being able to pass Units (meters, miles, yards).
2. Accepting the widest possible "complexity" of meaningful arguments. So, for the point a user can pass a simple number array (Position), or a bare geometry (Point), or a full on feature with properties (Feature<Point>). So the arguments would look like this instead:
   point: Feature<Point> | Point | Position
polygon: Feature<Polygon | MultiPolygon> | Polygon | MultiPolygon

Sorry if that's more involved than you expected. Happy to co-author though if your time is limited.

Thanks for pointing out the options. Missed that I can just forward this to the pointToLineDistance function. I also added a test that roughly reflects the initial issue question. For the sake of not complicating my test fixture setup I won't print out which point is the closest but pointB is the closest ;) which can be checked by comparing the expected distances of the three fixture points in the long-lines-poly.geojson.
I also added the expected unit to the test fixtures to validate that the unit conversion is working as expected.

@smallsaucepan anything else needed from my side?

@smallsaucepan done 👍

Thanks @pachacamac. Let's give it a spin through CI.

Little bump in the road related to the pnpm-lock file. Pushed a quick fix and CI is green, so this is ready to merge 🎉

Thanks for your work on this @pachacamac. This was our most 👍-ed outstanding issue.