Stricter known Object Key enforcement change proposal

[Harris-Miller]

Ramda functions like assoc current have the ability to set any property on an object. While there is nothing wrong with that, our current typescript definition for assoc allows for that by default in a non-type-safe way

Let's take a look at a pure javascript example

const obj = {
  foo: 0,
  bar: 0
};

// direct setters
obj.foo = 1;
obj.bar = 2;
obj.nope = 3;

// `pipe` and `assoc`
const nextObj = pipe(
  assoc('foo', 1),
  assoc('bar', 2),
  assoc('nope', 3),
)(obj);

In typescript, 90% of the time we work with strict object shapes

type Obj = {
  foo: number;
  bar: number;
};

And repeating the above example

const obj: Obj = {
  foo: 0,
  bar: 0
};

// direct setters
obj.foo = 1;
obj.bar = 2;
obj.nope = 3; // error: Property 'nope' does not exist on type 'Obj'.

The existing type definition for assoc, while does care about the type of obj, allows you to set unknown properties by altering the type definition of the input object with the key/value it sets

const nextObj = assoc('nope', 3, obj);
//    ^? const nextObj: Obj & Record<'nope', number>

IMHO, this side-steps the typescript' type-safety system

Even misspellings would be let through

const nextObj = assoc('fooo', 3, obj); // 'fooo' is allowed! although we certainly meant 'foo'

I am proposing that assoc, assocPath, prop, lensProp`, etc, basically any function that references obj keys directly, have their type definitions be changed to only allow for known keys.

This would align with what I believe is one of the core intentions of typescript. This would also be a major breaking change

Please note that objects that have mapped properties will still work as expected here

const obj: Obj = { foo: 1, bar: 2 };
assoc('whatever', 5, obj); // should error
prop('nope', obj) // should error and returns undefined

const dict: Record<string, number> = { foo: 1, bar: 2 };
assoc('whatever', 5, dict); // ok
prop('nope', dict) // ok, returns undefined

This is because the behavior would be no different from object literal getter/setters for the type Record<string, number>

In cases where you are using assoc or set to specifically alter the type from one to another, the same casting would be needed as if you were doing an in-place mutation

type ObjPlus = { additionalProp: string} & Obj;

const obj: Obj = {
  foo: 0,
  bar: 0
};

(obj as ObjPlus).additionalProp = 'no error because of the casting';

const objPlus = assoc('additionalProp', 'no error because of the casting', obj as ObjPlus);
//    ^? bonus is that `objPlus` is correctly typed as `ObjPlus` and not `Obj` here as well!

// this will also work in cases of `pipe` with an arrow function since `Obj` satisfies `ObjPlus`
pipe(
  func(/* something that returns an `Obj` */),
  (obj: ObjPlus) => assoc('additionalProp', 'no error because of the casting', ObjPlus)
); // this will return `ObjPlus` and not `Obj` when called

As previously mentioned, this significantly breaks the current typing behaviors for many functions of ramda (I'll add a complete list of those functions later)

What I'm looking for here and now is community feedback on if this would need to be a 0.30.0 update or even a 1.0.0 update. Even if that semver bump is just for types and not for any actual behavior.

[Harris-Miller]

I never got around to blasting this out to a broad audience to feedback, mostly because of the Reddit strike since I was unable to post to r/typescript or any other subreddit of the like

I have decided that this change falls under the category of what I'm calling "Type Safety" and should be merged in as "Breaking" but without a 0.30.0 or 1.0.0 release of ramda to coincide. And therefore will move forward with merging them regardless of them being "Breaking"

Mainly because this update is what I consider to be a fix for current behavior to what it should be. The current typings I consider to be "broken" in this regard

I have 2 MRs up to start with this

• Draft: Breaking: assoc, dissoc, and modify #37
• Breaking: prop #39