String.split() method's separator argument should allow undefined

[JohanRonnblom]

⚙ Compilation target

ES2024

⚙ Library

6.0.2

Missing / Incorrect Definition

String.split should allow undefined as its separator argument, resulting in an array containing the entire string.

Unlike the case of omitting the separator (#38331), this is a useful feature, since separator may be a variable, and it can be desirable to get an array with the entire string in the case that separator is not set, in order to not need a different code path for this case.

This feature is explicitly defined in the spec. It is not something that just 'happens to work', like using null or a number.

Sample Code

console.log("string,that could/split:but-should;not".split(undefined));

Documentation Link

https://tc39.es/ecma262/multipage/text-processing.html#sec-string.prototype.split

[MartinJohns]

This is essentially a duplicate of #38331. An argument being optional or undefined is the same.

And I would say that the original argument still holds true: it's more likely a mistake to pass undefined than it's intentional. And it's easy to provide the types in your own code base if you really want it.

[JohanRonnblom]

It's not the same, because while omitting the argument never makes sense, it makes perfect sense to pass a variable that can be undefined.

Here is a simple use case to illustrate this:

const highlightText = (text: string, highlight: string) =>
  text.split(highlight)
    .reduce((acc, fragment) => `${acc}<b>${highlight}</b>${fragment}`)

> highlightText('banana', 'a')
> -> 'b<b>a</b>n<b>a</b>n<b>a</b>'
>
> highlightText('banana', 'q')
> -> 'banana'
>
> highlightText('banana', '')
> -> 'b<b></b>a<b></b>n<b></b>a<b></b>n<b></b>a'
>
> highlightText('banana', undefined)
> -> 'banana'

More generally, for some code that uses split on a variable separator, the code will behave in a certain way when the variable separator does not occur in the string to be split. Setting the separator variable to undefined is a straightforward way to reliably obtain that result. This can be employed to get a more readable and maintainable code since there is no need to create a separate code path that duplicates the logic that already exists for the non-matching case.

[jcalz]

If you want to see this in your own code base, you can use declaration merging to add a call signature to split that allows string | Regexp | undefined or whatever you'd like.

If you want to see this in everyone's code base, then you'd need to argue that the change will, on average, be more beneficial than harmful, in real-world code. Like, you'd want to show that in the wild there are more intentional uses of an undefined separator than accidental ones. Otherwise this request looks like "I have a niche use case I'd like to impose on everyone".

[RyanCavanaugh]

[...] It is not something that just 'happens to work', like using null or a number.

This is in the spec too. Everything's in the spec. The spec doesn't say which part are good and which are bad.

The behavioral difference between split() and split(c) is super different and it's really hard to imagine a situation where the same codepath is doing either based on data. A code sample where this really makes sense would be useful but we'd really want a stronger feedback signal to change this.