String.prototype.split() with a regex containing a capturing group can return an array of string | undefined.

[loristhesnail]

⚙ Compilation target

any

⚙ Library

esnext, dom

Missing / Incorrect Definition

Using split with a negative lookahead and a capturing group can return undefined. See the attached screenshot. When iterating over the array, we lose type safety and encounter runtime errors.

Sample Code

'a,b,c'.split(/,(?!(a))/) // Types as string[]

Documentation Link

No response

[MartinJohns]

You need to enable noUncheckedIndexedAccess, that's what it is for.

Essentially a duplicate of #52299 and others.

[loristhesnail]

Not really, it is a different issue.... I searched these before.

This should thrown a type error.

'a,b,c'.split(/,(?!(a))/).forEach((v) => {
  console.log(v.includes('something'))
})

[nmain]

noUncheckedIndexedAccess won't change the types on forEach, map, for .. of, etc because they're not access from an index signature.

[jcalz]

Yeah, this is a different issue.

There's a type safety hazard here for sure, given that the resulting array literally contains undefined, so --noUncheckedIndexedAccess doesn't help (if it were a sparse array then it would be weird but fine). But this is really an edge case, isn't it? TS wants to be type safe but not at the expense of productivity. In real world code, what percentage of uses of split() run into this? I'm guessing it's below 1%. That would mean for 99% of the code out there that uses split() today and has no problem, suddenly there's a useless compiler error they have to deal with. That would annoy everyone, and then people would just learn to ignore it (e.g., v!.includes('something')) , so if they do ever hit the real problem, they'd just hit it at runtime also. Can someone make an argument that the cure is better than the disease?

[nmain]

If #32098 was implemented, that would lead towards a more precise solution here: The RegExp type would be generic in whether it had capture groups, and regex literals would automatically have the right generic parameters filled in for their inferred type. That could then infect the typings of things like RegExp.protoype[Symbol.split] and from there String.prototype.split.

Seems like a lot of work though.