This kata is unsolvable now (due to Node 18. being the only available version) because author does not know how to do object comparison using assert and chai...

isNearby uses Manhattan distance for some reasons. This needs to be specified because this is certainly unexpected (usually distance defaults to Euclidean distance), and because the distance metric will affect how to approach the kata (e.g Euclidean distance will be more difficult to handle than Manhattan distance).

Besides all of this, what is considered "nearby" should be defined in the description anyway instead of just providing a function to the user, so it is clear what the criteria actually is as a spec.

Performance is required by the kata, but the input range is unknown, so it's difficult to know what kind of solution the kata expects.

The local test have too few tourists. Landmarks are effectively sorted by id, not by number of tourists, because it's zero across the board in the vast majority of cases.

Also, the local tests don't prepare for the barrage of tourists in the final tests, but that's more of a problem with the final tests rather than with the local tests.

It took me two complete rewrites and even then trying repeatedly (during several hours) to get my solution submitted without timing out.

I have no problem with optimising code but if I have to grind through a million landmark-tourists 200 times dozens of times to find an especially calm timeslot on a server to get my code submitted, this kata is part of the problem, not of the solution.