@swc/wasm-typescript handling () => <T>{}

[acutmore]

Describe the bug

TypeScript's (legacy) prefix style type assertions (<Type>val instead of (val as Type)) cannot always be safely removed in "strip-only" mode when they are at the start of the body of an arrow function.

Input code

import * as swc from "@swc/wasm-typescript";

const input = `(() => <any>{})`;
const output = swc.transformSync(input, { mode: "strip-only" });

console.log(output.code);

Config

{ "mode": "strip-only" }

Playground link (or link to the minimal reproduction)

no playground support for wasm-typescript yet: swc-project/swc-playground#42

SWC Info output

No response

Expected behavior

Either error or (if possible) produce JS with matching semantics as the input i.e. the equivalent of: () => ({});

Actual behavior

Resulting code is: (() => {}) which has different semantics to the input.

Version

@swc/wasm-typescript@1.7.0

Additional context

I think it's not possible to solve this in all cases. So it might be best to error for arrow functions that start with <Type>{.

There are some cases that can work with "strip-only":

let f = () => <T>{};

can strip and keep the JS in place with:

let f = () => 0||{};

But that approach does not work for:

let f = () => <T>{p:null}.p ?? g();

which could not be changed to:

let f = () => 0||{p:null}.p ?? g();

As it is invalid to have || and ?? at the same level.

I would be very interesting if there was a way to solve this, otherwise I think the solution is to error.

[kdy1]

TypeScript's (legacy) prefix style type assertions (val instead of (val as Type)) cannot always be safely removed in "strip-only" mode when they are at the start of the body of an arrow function.

That's why we don't touch it.

[acutmore]

That's why we don't touch it.

Hi @kdy1, thanks for taking a look. In my testing it looks like "strip-types" does remove it.

(() => <any>{}) becomes (() => {}). The first returns {} at runtime, the second returns undefined.

For the case where the arrow function body only contains the type-assertion and object literal I think there is a safe transform to: (() => 0||{}), which keeps the original JS in the same position with the same semantics. However there are niche inputs which I think don't have safe position-preserving transforms such as: (() => <T>{p:null}.p??g), though I admit the chances of someone writing that is low.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.