Bloomberg feedback for 5.1 beta

[dragomirtitian]

We are in the process of evaluating the impact of upgrading to TypeScript 5.1 on our codebase. Here are some preliminary findings up to version 5.1.0-dev.20230502.

This is shaping up to be a low impact release. The following table lists changes that affected our codebase:

#	Change	Affects	Release notes	Packages affected
1	Changes to the typing of bind	Type Checking	Not Announced	~1%
2	Get accessor type is now more permissive	Type Checking	Announced	1
3	{ …{} } now emitted as {} in JSX tags	JS Emit	Not Announced	~1%
4	Usage of ?? in compiler code	Compiler	Announced	-

Changes to the typing of bind

This was the biggest impact change. The stricter types have caught several instances of useless or even wrong parameters being passed to a function through calls to bind. This was definitely an improvement for us.

Get accessor type is now more permissive

We already had in our code base a get accessor that was not in line with the previous restrictions. It was using ts-expect-error to suppress the error that now no longer exists (we switched to ts-ignore for now). This feature is welcomed and we look forward to removing the error suppression altogether when the migration to 5.1 is complete.

{ …{} } now emitted as {} in JSX tags

This change seems completely benign. Under ES Next this code <Component {...{ x: 0}} /> would previously emit React.createElement(Component, { ...{ x: 0 } }); in 5.1 it emits React.createElement(Component, { x: 0 });. In our tool chain terser would already perform this transformation, so this is a net 0 runtime impact for us.

Usage of ?? in compiler code

We need to support running the compiler itself (not the output of the compiler) on runtimes that don’t yet have support for the ?? operator. We plan to drop support for these runtimes in the medium-term, however in the interim we need to down-level the usage of ?? in the TypeScript compiler code.

[jakebailey]

We need to support running the compiler itself (not the output of the compiler) on runtimes that don’t yet have support for the ?? operator. We plan to drop support for these runtimes in the medium-term, however in the interim we need to down-level the usage of ?? in the TypeScript compiler code.

I'm interested in this; what runtimes are you using which don't have this? Is our bumping of the target too breaky, or is the effort acceptable?

[RyanCavanaugh]

It was pretty contentious during the design meeting, so I'd love to hear about the divergent getter setter pairs you have

[tchetwin]

I'm interested in this; what runtimes are you using which don't have this? Is our bumping of the target too breaky, or is the effort acceptable?

It's an older Node runtime in a single constrained application with an associated KTLO task to modernise it. I think the bump was conservative & acceptable and we have been able to work with it in this instanace.

[fatcerberus]

It was using ts-expect-error to suppress the error that now no longer exists (we switched to ts-ignore for now)

Huh, I admit it never occurred to me that people might do this. Feels like it defeats the purpose of @ts-expect-error (that you're reminded to remove it as soon as it's no longer needed, unlike @ts-ignore) if it's just going to be immediately replaced with a full-on @ts-ignore for BC reasons.

[RyanCavanaugh]

People usually tell me that they don't want the ts-ignore to "stick around forever"; there's more of a trade off than might seem at first. I don't use either construct 🤷‍♂️

[dragomirtitian]

@RyanCavanaugh The fields associated with the accessor starts out as null, but nobody is allowed to set it to null:

Something like

class ProcessWrapper {
    #processId: number | null = null
    get processId(): number | null {
        return this.#processId;
    }

    set processId(value: number) {
        this.#processId = value;
    }    
}

Playground Link

[dragomirtitian]

It was using ts-expect-error to suppress the error that now no longer exists (we switched to ts-ignore for now)

Huh, I admit it never occurred to me that people might do this. Feels like it defeats the purpose of @ts-expect-error (that you're reminded to remove it as soon as it's no longer needed, unlike @ts-ignore) if it's just going to be immediately replaced with a full-on @ts-ignore for BC reasons.

@fatcerberus It did do it's job to draw attention to fact the problem is no longer there. But we need to build with both TS versions for a short while so we need to clean it up after the transition period ends.

[fatcerberus]

@dragomirtitian That's what I mean; you've removed the safety valve so to speak, the compiler can no longer remind you it's not needed anymore and (disclaimer: speaking for myself here) I'd probably forget to remove it after that "transition period" without the reminder, which (to me) makes it no better than just writing it as a ts-ignore in the first place.

Maybe someday we could have @ts-ignore with a version range, so you can be reminded to review them in new TS versions...