Overloads for String.prototype.split method

[EzioMercer]

⚙ Compilation target

ES2020

⚙ Library

lib.es5.d.ts

Missing / Incorrect Definition

It is not wrong definition, but if it is possible, I would like to suggest add overloads for String.prototype.split method

I like to use string template types instead of just string as much as possible, and it works like a charm. The problem is that when I try to split my well-known string, it returns just string[] type which isn't very descriptive

My suggestion is to add simple overloads:

1. When the separator is string and limit is not provided or undefined
2. When the separator is string | RegExp and limit is 0

I added zero to the list because it is straightforward to implement that case, but if it means that I also should provide type checking for negative values, noninteger values and correct tuple splitting type then forget about it 😁

We can completely remove limit from overloads. I added it just to get the same type for provided limit as undefined and not provided limit otherwise the return type will be string[] if the value of limit is undefined

Sample Code

type Split<Source extends string, Separator extends string> = Source extends `${infer Left}${Separator}${infer Right}`
    ? [...(string extends Left ? string[] : [`${Left}`]), ...Split<Right, Separator>]
    : Source extends ""
      ? Separator extends ""
          ? []
          : [""]
      : string extends Source
        ? string[]
        : [Source];

interface String {
    split<Source extends string, Separator extends string>(
        this: Source,
        separator: Separator,
        limit?: undefined,
    ): Split<Source, Separator>;

    split(separator: string | RegExp, limit: 0): [];
}

You can see types in action on playground (with examples)

Documentation Link

No response

[MartinJohns]

Duplicate of #56333 / #53362.

[EzioMercer]

@MartinJohns @RyanCavanaugh I don't think that it is a duplicate because in mentioned (and other) issues a lot of cases didn't handled. Please look at playground link which I provided

[EzioMercer]

@RyanCavanaugh Please give it a chance. I really did my best to write these overloads. I covered a lot of edge cases. I gave about 20 cases that I could think of, but if there are uncovered edge cases that don't work, please feel free to add them in the comments, I'll try to handle them too.

[MartinJohns]

It's still a duplicate. Another approach doesn't justify a new issue. You can add your suggestion in the open issue, which is still labelled as "Awaiting More Feedback".

Also this comment is relevant: #53362 (comment)

we have a pretty low appetite for making the standard library definitions extremely complex for the sake of NUIA

Your suggestion is extremely complex for a corner case and requires the addition of a new utility type (potentially causing conflicts with user code). See also No New Utility Types.

[EzioMercer]

@MartinJohns I simplified a little my type. I am not a genius of TypeScript so may be someone can come up with less complex definition.

You can add your suggestion in the open issue

I will. Thank you for noticing that

requires the addition of a new utility type

1. I didn't mean to export this type I thought it can be used "hidden"
2. The name of this type can be anything like UnsafeSplitTypeOnlyForStringCasesInStringSplitMethod or etc.

we have a pretty low appetite for making the standard library definitions

I can't quite understand this. Don't we want to give the user as much information as possible? I understand that it's almost impossible to do everywhere, but why not where it's not that hard?

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.