Suggestion: Support for native functions

[Ceedrich]

Suggestion: Support for native functions

I love, how your library enhances the typescript experience when working with literal types. However, it is kind of exhausting to always use the library's functions instead of the native javascript ones.
Would you consider (maybe as an option) mapping the string-ts types onto the native javascript functions (see example below)?

---

Example:

Before:

import { join } form "string-ts"

const joinedString = join(["some", "literal", "string"], " ")
//    ^? "some literal array"

After:

const joinedString = ["some", "literal", "string"].join(" ")
//    ^? "some literal array"

I am looking forward to your evaluation

[gustavoguichard]

Hey @Ceedrich , thanks for contributing. Sorry for the late reply I somehow lost your notification in my inbox.

Even though it is not in our roadmap and I think it could be too much to add it onto the native functions I'm open to the idea and would love to hear some suggestion about it.

[joneshf]

Saw this in passing. If you're looking for how to actually implement it, I think you could do something like extending the global namespace:

declare global {
  interface ReadonlyArray<T> {
    join<const T extends readonly string[], D extends string = ''>(this: T, separator?: D): Join<T, D>;
  }
}

I'm just lifting the type signature from

string-ts/src/native/join.ts

Lines 33 to 36 in 6196f56

	export function join<const T extends readonly string[], D extends string = ''>(
	tuple: T,
	delimiter: D = '' as D,
	) {

It's possible there's a different signature you can use that would work better.

Playground link.

[joneshf]

I'm not sure how much it matters, but you also wouldn't have to worry about tree shaking this native stuff. It's all at the type level, so it wouldn't end up in the bundle anyway.

The things that aren't on the native objects (like capitalize) would still require it, though.

[gustavoguichard]

Hey @joneshf ! The implementation seems trivial indeed.
I never really cared much about it because I think it is too much to make a project-wide commitment.
But I'm getting interested on doing it given there's quite a few people that would like to have such possibility.

I just need to think of a good API for that.
Do you have any suggestion on what would be a good DX to partially/totally setup string-ts types on native functions?

[gustavoguichard]

@Ceedrich also might want to suggest something

Do you have any suggestion on what would be a good DX to partially/totally setup string-ts types on native functions?

[Ceedrich]

Do you have any suggestion on what would be a good DX to partially/totally setup string-ts types on native functions?

I think the best developer experience as a consumer would be to just be able to have the stricter typings of string-ts without having to worry about importing and getting used to new function signatures.

This should be possible just by declaring the types of the native functions in a global .d.ts file.

The user would still be able to use the additional functions the library provides and use the native ones with better typing.

Another thought on that: are there any scenarios where you would prefer the native typings to the ones string-ts provides?

Personally however, I would eventually deprecate the wrapper functions around the native ones as they are generally more unintuitive. About this last part, I am not actually sure and looking forward to hearing your thoughts.