Repository navigation
[transpileDeclaration API][5.5] More missing type-only imports #58511
Description
🔎 Search Terms
transpiledeclaration api emit missing import
🕗 Version & Regression Information
- This changed in commit or PR Add
transpileDeclarationAPI method #58261 Wesley Wigham (@weswigham)
⏯ Playground Link
💻 Code
// @strict: true
// @declaration: true
// @showEmit
// @showEmittedFile: a.d.ts
// @showEmittedFile: b.d.ts
// @filename: a.ts
export interface In {
[key: string]: unknown;
}
export interface Out {
[key: string]: unknown;
}
export type Base = 'a' | 'b';
// @filename: b.ts
import { type In, type Out, type Base } from "./a";
export const object = {
doThing<T extends Base>(_t: T, _in: In[T]): Out[T] {
return;
},
};🙁 Actual behavior
When using the API, b.d.ts is emitted as
import { type In } from "./a";
export declare const object: {
doThing<T extends Base>(_t: T, _in: In[T]): Out;
};while when using tsc it gets emitted as
import { type In, type Out, type Base } from "./a";
export declare const object: {
doThing<T extends Base>(_t: T, _in: In[T]): Out[T];
};(interestingly the Debug tab of the workbench link shows something that's partially wrong)
🙂 Expected behavior
Using the API should emit
import { type In, type Out, type Base } from "./a";
export declare const object: {
doThing<T extends Base>(_t: T, _in: In[T]): Out[T];
};Additional information about the issue
No response
Activity
MichaelMitchell-at commentedon May 13, 2024
I'm somewhat worried that trying to adapt checker.ts to also be able to purely emit declarations will lead to more problems like these to continue to arise. It seems harder to reason about than the behavior we'd expect with isolated declarations - a mostly syntactic transformation. I'm concerned that these discrepancies will lead to compatibility issues when migrating to alternative implementations such as likely ones like ESBuild.
weswigham commentedon May 13, 2024
This is partially fixed by #58522 - the
Outis elided because we don't traverse theOut[T]node for reuse (and instead use anOut-printing error type node). TheBasereference is a separate issue, so this gets to stay open - looks like we're failing to collect references from the type parameter constraint position in our references visitor (which is separate from the checker's node builder and largely standalone - the references visitor was always intended to be reused since import tracking is common functionality that all declaration emitters need to support elision).dragomirtitian commentedon May 15, 2024
michaelm (@MichaelMitchell-at) We have the same concerns, and we are working to mitigate them.
While the errors for isolated declarations have been merged, we are still working on:
checker.tsis not accidentally being used during the emit of.d.tsfiles.To elaborate on the second item, we are planning to extract a lot of the type reuse logic from checker.ts. This extracted type node builder (that will only use syntactic information) together with some other pieces we have already extracted (name resolution, evaluator) and other pieces we still need to extract (visibility checks) will be used to build a test declaration emitter that will not depend on checker.ts. This can be use to both prove that TS does not use any forbidden knowledge when emitting d.ts files in isolated declaration mode and it can serve as a blueprint for what other implementations need to reimplement in order to produce a similar emit (without needing to reason about the whole checker)
MichaelMitchell-at commentedon May 15, 2024
Awesome! These changes continuing to be driven by folks at Bloomberg give us more confidence that isolated declarations will converge to be practical and impactful in large composite projects. At Airtable we're gradually migrating more projects to isolated declarations, which is helping to uncover bugs/edge cases and we'll continue to do so, though if there's anything we can contribute code-wise, we might be able to allocate some engineering time towards that. Please, let us know if there are any areas of opportunity for that. In particular, we'd be very interested in anything we can do to leverage isolated declarations to improve TSServer performance in VSCode. Editor performance has been the top pain point for our developers when it comes to our TypeScript usage.