setPath only works for existing properties

[bombillazo]

Hello, looking at the setPath logic, it seems to check if the path value on the object is not null/undefined before attempting to insert the new value. How can we set a new value to the object that is not yet defined?

[cjquines]

the trouble with this is with undefined deeply nested paths:

type T = Record<string, { a: number; b: number }>;
const obj: T = {};

R.setPath(obj, ["test", "a"], 2);

there's no way to do this type-safely if obj.test isn't defined

[bombillazo]

Hey, yeah i figured if proper typing is a tenet of this library, it's gonna be hard to infer/produce a dynamic, nested property...

It would be awesome, though. Not sure if one can create a dynamic type from a path, and make a union of the input param generic type with that dynamic type to type the output.

[Brodzko]

I stumbled upon a similar problem recently - I think it technically might even be possible to write a function like that type-safely(ish), but there might be too many decisions on how to handle edge-cases to have this on a library level.
For example, what if the path contains an array index that is non-zero, but its parent property does not exist in target? Do you put the value at index 0 (thus not really upholding contract), or risk creating a sparse array?

I'm not sure there are canonical answers to this and other edge-case questions, so it feels like something that should remain in user-land.

I ended up ignoring array properties (didn't need them) and recursively creating a new object using objOf + some type magic to create a type from path in the end.