[WIP] fix(propEq): improve propEq typings

[Nemo108]

• remove unnecessary constraint from propEq value: the function should receive any type values of object, no matter what parameter it received;
• add additional types to use with placeholder

[Harris-Miller]

@Nemo108 I finally got around to re-checking and merging #71. Rebase this one for me and I'll recheck it

[Nemo108]

@Harris-Miller done

[Harris-Miller]

${number} is a neat trick! Allows strings that only contain number characters, very cool

[Harris-Miller]

We don't want to WidenLiterals<U[K]> here. When we know the type of U, we want to constrain val to U[K]

type Obj = {
  prop: 'foo' | 'bar'
};

// we want to disallow strings other than `'foo'` and `'bar'` here for `val`
propEq('biz', 'prop', obj);

WidenLiterals<U[K]> is needed for the curried versions before of how typescript infers types

const doesEqualFoo = propEq('foo', 'prop');

// without `WidenLiterals<U[K]>`, the type would be `Record<'prop', 'foo'>`, but obj is `{ prop: 'foo' | 'bar' }`, which is too wide for just `'foo'`.
// with `WidenLiterals<U[K]>`, the type would be `Record<'prop', string>`, so `obj` is allowed
doesEqualFoo(obj)

Typescript doesn't support currying like this that well in general, but we do the best we can with what we have

[Harris-Miller]

Instead of the ternary, we do 2 overloads

export function propEq<K extends number>(__: Placeholder, name: K): {
  // ...
}
export function propEq<K extends Exclude<PropertyKey, number>>(__: Placeholder, name: K): {
  // ...
}

[Harris-Miller]

I don't think const U in needed here. U should be find.

You need to constrain U and K here though. If typeof U[K] as well. Turns out you don't need WidenLiterals here at all, in fact, it would actually break if U[K] was string | number but you passed a string to val: V.

See here: https://tsplay.dev/m3KbAm

[Nemo108]

V extends U[K] ? U : never creates too strict constraint: it fires an error on any string I pass there

https://tsplay.dev/wOXozN

But I think I came up with a better solution

[Harris-Miller]

@Nemo108 I'm having to revert the other propEq we collaborated on together: #74 (see: #99)

This MR is actually of of develop before that merge, so after the revert happens there should be no more merge conflict.

The additions made to #74 solved a different problem about propEq. I pretty sure the changes in this MR are find to merge without those changes. I'm also pretty sure that the specific change of #74 that broke it (argument possibly being never) not present in these changes, so we shouldn't have that problem again

[Harris-Miller]

Suggested change

	import { Placeholder } from 'ramda';
	import { WidenLiterals } from '../util/tools';
	import { Placeholder, WidenLiterals } from '../util/tools';

[Harris-Miller]

Ah crap, I missed this when I left that other comment about this MR not being a problem

array: V extends U[K] ? V[] : never

This is the thing we can't have. It breaks combining with other functions, egR.filter(R.propEq('type', 'something')). The predicate type signatures don't match because of the : never