`Paths` should not recurse into `Map`'s prototype properties. about type-fest HOT 9 CLOSED

@sindresorhus

from type-fest.

I think it should be opt-in. Map would require using a different way to access the values using the path components.

Set does not make sense as it's not indexed.

from type-fest.

Map would require using a different way to access the values using the path components.

I agree opt-in, but it doesn't seem possible to use string to represent all type of the keys in Map, like object key.
The most we can do is to access only the string/number keys in Map.

from type-fest.

That's fine.

from type-fest.

@sindresorhus I thought about it more. If the reason for using opt-in is that access to a map is different from access to an object, but if the user chooses recurseInMap, the final result is still indistinguishable from a map or an object.

so maybe opt-in isn't necessary?

and if we can't tell the difference between the path of map or object, should we don't recurse in?

from type-fest.

The main reason for making it opt-in, is that most times when you need to get the paths, you don't support Map. For example, with https://github.com/sindresorhus/dot-prop, I don't support Map, so I wouldn't want the user to get autocomplete for Map keys.

from type-fest.

The main reason for making it opt-in, is that most times when you need to get the paths, you don't support Map. For example, with https://github.com/sindresorhus/dot-prop, I don't support Map, so I wouldn't want the user to get autocomplete for Map keys.

got it. maybe we shoudn't support recurse into map?

from type-fest.

Yeah, maybe we should wait until someone requests it. I personally don't have any need for it.

from type-fest.

Yeah, maybe we should wait until someone requests it. I personally don't have any need for it.

ok, but look at image in the description, there is still a bug that Paths should not recurse into Map's prototype properties.

from type-fest.