Open spenceryue opened 3 years ago
I narrowed down the "specified node" (referenced in the error message) by logging
node.getText()
andnode.getSourceFile().fileName
here (just before the error is thrown).
This should probably be reported as InternalError
and the message should include more context using SourceFileLocationFormatter.formatDeclaration()
.
The problem is caused by newfangled type algebra T: any
that puts a ts.SyntaxKind.PropertySignature
in a place where a property name normally goes.
It is basically an assertion failure, because getChildAstDeclarationByNode()
expects that node to have been traversed previously, but it wasn't, because T
is hiding in a place were the visitor does not look for types:
Without investigating deeper, my guess is that the type algebra has evolved to a level of complexity where AstDeclaration.isSupportedSyntaxKind()
is no longer a sufficient test.
The problem is caused by newfangled type algebra T: any that puts a ts.SyntaxKind.PropertySignature in a place where a property name normally goes.
It seems from this thread that .PropertySignature
is a pretty old concept (6 years).
Just to clarify, in the reproduction, the intent is not to somehow use the T
parameter as a computed property name or index signature. The intent is just to have a field literally named "T"
. A more realistic usage:
interface SomeLongComputation<T> {
// Refine the "raw" `T`.
T: Extract<T, Foo>;
// No type error about "`T` doesn't extend `Foo`".
result: DoSomethingWith<this["T"]>;
}
// Notice the `extends Foo`.
type DoSomethingWith<T extends Foo> = T;
// Usage:
SomeLongComputation<T>["result"]
Analogous runtime code:
type Foo = {};
const someLongComputation = (t: any) => ({
t: isFoo(t) ? t : "never",
get result() {
return doSomethingWith(this.t);
},
});
const isFoo = (t: any): t is Foo => true;
const doSomethingWith = (t: Foo | "never") => t;
// Usage:
someLongComputation(t).result
Summary
I was trying to flatten the
d.ts
files output by Angular 10 (as recommended here), because the strayd.ts
files seemed to cause issues when passed into ngcc (Error: Compiled class declaration is not inside an IIFE
).Repro steps
Minimal entry file to reproduce error:
Config:
Command:
Details
I narrowed down the "specified node" (referenced in the error message) by logging
node.getText()
andnode.getSourceFile().fileName
here (just before the error is thrown).When I logged the following at line 681 (the only place that
this._astDeclarationsByDeclaration.set
is ever called), I saw that indeed the "specified node" was never printed.Here's is the output with
--diagnostics
. (Note: The second line of textAnalysis will use the bundled TypeScript version 4.3.5
seems wrong. I'm using TS 4.0.8.)Standard questions
Please answer these questions to help us investigate your issue more quickly:
@microsoft/api-extractor
version?node -v
)?