Problem
At the moment we are shipping hand-written .d.ts files for the generators which are pretty deficient. For example, javacript.d.ts (copied into the package from typings/javascript.d.ts) is essentially:
export enum Order {
ATOMIC = 0, // 0 "" ...
// etc.
NONE = 99, // (...)
}
export declare const javascriptGenerator: any;
Note that javascriptGenerator is declared as any, and JavascriptGenerator is not declared at all.
This means that developers using generators from TypeScript are not getting the full benefit of TS's type checking of the generator classes / instances.
Proposed Solution
Publish the .d.ts files produced by tsc instead of these handwritten versions.
Discussion
- Should we publish individual
.d.ts files in dist/generators/**/*.d.ts (as we do for files in core), with a wrapper that just imports them, or should we try to publish a single file per chunk that rolls these up?
- There may be some difficult in publishing a roll up as it will need to reference
CodeGenerator, which is currently defined in core/.
See also #5818.
Problem
At the moment we are shipping hand-written
.d.tsfiles for the generators which are pretty deficient. For example,javacript.d.ts(copied into the package fromtypings/javascript.d.ts) is essentially:Note that
javascriptGeneratoris declared asany, andJavascriptGeneratoris not declared at all.This means that developers using generators from TypeScript are not getting the full benefit of TS's type checking of the generator classes / instances.
Proposed Solution
Publish the
.d.tsfiles produced bytscinstead of these handwritten versions.blocks/andgenerators/to TypeScript #6828build_tasks.jsandpackage_tasks.jsaccordingly.typings/*.js.Discussion
.d.tsfiles indist/generators/**/*.d.ts(as we do for files in core), with a wrapper that just imports them, or should we try to publish a single file per chunk that rolls these up?CodeGenerator, which is currently defined incore/.See also #5818.