Should we expand this library beyond strings?

[gustavoguichard]

As I keep saying over and over, the goal of this library is to have strongly-typed functions that work seamlessly between type and runtime worlds.

This concepts perfectly applies to strings, but what if we could start going beyond strings?
We actually already have a method that works on Array: join but I started thinking we could also be adding more methods to improve the DX of TS folks in general.

With that in mind I was playing this morning with the following:

I know the folks from ts-reset (@mattpocock) are discouraging) strongly typing Object.keys and Object.entries but I think the goal of that library is completely different as they aim to solve some weaknesses of TS without being overly intrusive because it changes your whole codebase. But in string-ts we can import functions on demand for maybe just a couple cases in a whole codebase.

We know a type may deviate from its runtime value but shouldn't we be able to choose when to trust our guts?
@colinhacks wrote an amazing case about it when he was trying to implement end-to-end type-safety in Remix despite the Remix core team back then were not in favor of it.
So if we drop the purism we might excel in DX.

And as we move on with our tree-shaking capabilities I think it should be safe to add more methods.

Going back to the example on the image above, notice that objKeys is NOT returning ('a' | 'b' | 'c')[] which is quite easy but it is returning ['a', 'b', 'c'] which is a much harder problem and thus it may improve the overall DX to a whole new level.

These are just random thoughts I had today and would love to hear some opinions on it.

@p9f , @jly36963 , others?

[p9f]

going beyond strings

I think what is important is for the library to have a clear focus. As I understand it, the current focus is "strongly typed utilities function for strings" which seems quite clear.
If we want to add things outside of this focus, it might makes sense to first define what the new focus should be?

defining a strongly typed keys function

I think what should drive our decisions is the consistency between runtime behaviour and types - ensuring the typescript don't "lie" to us. Hence I prefer to have a type less precise but true.
I can really see a lot of bugs happening from such a keys function, as it will be very easy for most programmer to not know that actually, the type might be wrong:

type User {
  id: string;
}
type NamedUser {
  id: string;
  name: string;
}
const user: User = { id: "123", name: "Joe"}

keys(user);
   // runtine value is ["id", "name"]
   // type is ["id"] 

this seems a clear deal breaker to me.

(I think the remix PR linked is different - the "lie" is not coming from a wrong type but from the network chasm)

shouldn't we be able to choose when to trust our gut

I do think we should! we can by using an explicit casting as, and it makes it clearly explicit to the reader.

notice that objKeys is NOT returning ('a' | 'b' | 'c')[] which is quite easy but it is returning ['a', 'b', 'c']

Similar - I don't think we can achieve this with typescript?

type NamedUser {
  id: string;
  name: string;
}
const user: NamedUser = { name: "Joe", id: "321" };

keys(user);
   // runtine value is ["name", "id"]
   // type is ["id", "name"]