TypeScript icon indicating copy to clipboard operation
TypeScript copied to clipboard

[transpileDeclaration API][5.5] Type assertion is ignored

Open MichaelMitchell-at opened this issue 1 year ago • 4 comments

🔎 Search Terms

transpiledeclaration type assertion as cast unknown promise async await

🕗 Version & Regression Information

5.5.0-dev.20240517

⏯ Playground Link

https://www.typescriptlang.org/dev/bug-workbench/?target=7&ts=5.5.0-dev.20240502#code/PTAEAEGcBcCcEsDG0Bco4FcCmAoEEATLRAGwENYzp4B7AOzU13ygAsaB3AUQFt5o8YNp179oWAgDF4JLGjIA6AguiQcgiADMZWOmR5zQi1TiwAPAA41Y0I5ACedRKE0Yn1ei5o0AFAEpQAG8cUFBYLGgMWDpQHzIOMn5QABYAJgCySFA6DB4AIyxYAG4cAF8cIA

💻 Code

// @strict: true
// @declaration: true
// @showEmit
// @showEmittedFile: a.d.ts

// @filename: a.ts
export async function foo() {
  return (await 42) as number;
}

Workbench Repro

🙁 Actual behavior

When using the API, a.d.ts is emitted as

export declare function foo(): unknown;

while when using tsc it gets emitted as

export declare function foo(): Promise<number>;

🙂 Expected behavior

Using the API should emit

export declare function foo(): Promise<number>;

Additional information about the issue

This might be the last issue within all the projects we've enabled isolated declarations for so far \o/ (still have many more to go though) which means that we soon might be able to enable parallel typechecking by default.

MichaelMitchell-at avatar May 17 '24 22:05 MichaelMitchell-at

Hm, I think this one might be because Promise isn't defined in the lib transpileDeclaration uses, and async functions always have to Promise-wrap their returns (so it's not like the cast type node is usable without modification). On the other hand, the missing Promise type probably only matters because we don't have the logic to syntactically promise-wrap a cast's type node when the function is async.

@dragomirtitian thoughts? Technically, syntactically promise wrapping the cast node isn't fully correct, since if the cast is to another promise type, you should unwrap it and then promise wrap that unwrapped thing (as MyPromise should become a Promise<something> return type)... So in that respect, there should be an ID error for this.

weswigham avatar May 17 '24 23:05 weswigham

I think there's something fishy with the Workbench tool. Even without any promise wrapping, even on TS 5.4, the workbench DTS output pane incorrect states unknown despite the hover-completion correctly showing the return type as Promise<number>.

// @declaration: true
// @showEmit
// @showEmittedFile: a.d.ts

// @filename: a.ts
export async function foo() {
  return 42;
}

Workbench Repro


a.d.ts as reported by Workbench output pane:

export declare function foo(): unknown;

robpalme avatar May 18 '24 11:05 robpalme

:wave: Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of the repro in the issue body running against the nightly TypeScript.


Issue body code block by @MichaelMitchell-at

:+1: Compiled
Emit:

export declare function foo(): Promise<number>;

Historical Information
Version Reproduction Outputs
5.0.2, 5.1.3, 5.2.2, 5.3.2, 5.4.2

:+1: Compiled
Emit:

export declare function foo(): Promise<number>;

typescript-bot avatar May 19 '24 08:05 typescript-bot

:wave: Hi, I'm the Repro bot. I can help narrow down and track compiler bugs across releases! This comment reflects the current state of this repro running against the nightly TypeScript.


Comment by @robpalme

:+1: Compiled
Emit:

export declare function foo(): Promise<number>;

Historical Information
Version Reproduction Outputs
5.0.2, 5.1.3, 5.2.2, 5.3.2, 5.4.2

:+1: Compiled
Emit:

export declare function foo(): Promise<number>;

typescript-bot avatar May 19 '24 08:05 typescript-bot