fix(cli/dts): add typings for Change Array by copy proposal

[crowlKats]

Closes #16496

[bartlomieju]

Please update tools/update_typescript.md in point 6. about lib.esnext.array.d.ts

[sno2]

I was also thinking, we might want to make the toSpliced follow the same suggested technique as with by allowing new types to be included in the array as the resultant array would be considered a new entity.

Edit: these changes can be upstreamed afterwards as well: microsoft/TypeScript#50333

[sno2]

(Copied from resolved comment thread)

built-in typings arent ever complex typings like that, so we will leave it to any.

I'm not sure if it's that simple why there aren't complex typings. Many of the array methods were implemented in far older type systems so they did not have the ability to use these new type features without breaking old code. I'd consider this an inflection point in improving the user-experience with types. Also, if you type this as any, then no one who cares about sufficiently safe code will want to use this new feature. Please reconsider.

Edit: There has also been a shift in the official typescript typings towards using more complex types in an effort to improve DX. Some examples:

• https://github.com/microsoft/TypeScript/blob/main/lib/lib.es2021.promise.d.ts#L42
• https://github.com/microsoft/TypeScript/blob/main/lib/lib.es2020.promise.d.ts#L40
• https://github.com/microsoft/TypeScript/blob/main/lib/lib.es2022.sharedmemory.d.ts#L26

[bartlomieju]

(Copied from resolved comment thread)

built-in typings arent ever complex typings like that, so we will leave it to any.

I'm not sure if it's that simple why there aren't complex typings. Many of the array methods were implemented in far older type systems so they did not have the ability to use these new type features without breaking old code. I'd consider this an inflection point in improving the user-experience with types. Also, if you type this as any, then no one who cares about sufficiently safe code will want to use this new feature. Please reconsider.

Edit: There has also been a shift in the official typescript typings towards using more complex types in an effort to improve DX. Some examples:

• https://github.com/microsoft/TypeScript/blob/main/lib/lib.es2021.promise.d.ts#L42
• https://github.com/microsoft/TypeScript/blob/main/lib/lib.es2020.promise.d.ts#L40
• https://github.com/microsoft/TypeScript/blob/main/lib/lib.es2022.sharedmemory.d.ts#L26

@sno2 this is a stop-gap solution until TypeScript supports this feature officially. I believe it's better to use looser types now and narrow them later, than be too strict right now.

[sno2]

I believe it's better to use looser types now and narrow them later, than be too strict right now.

Why release loose types only to break libraries and codebases a few months later? You can always add looser behavior later if the typescript team somehow chooses to use any typing instead.

[bartlomieju]

I believe it's better to use looser types now and narrow them later, than be too strict right now.

Why release loose types only to break libraries and codebases a few months later?

Okay, after confering with other team members it seems it's better to go with too strict than too loose types here. Thanks for bringing this up @sno2!

[bartlomieju]

LGTM, thanks for taking care of this Leo