[api-extractor] Report unresolvable inline import paths in .d.ts rollups - #5925
[api-extractor] Report unresolvable inline import paths in .d.ts rollups#5925Phạm Mạnh Lực (MLuc24) wants to merge 1 commit into
Conversation
When an inline import() type could not be resolved to a rolled up entity, its
span was emitted verbatim. A relative path such as import('../Bar') means
nothing next to the rollup, which does not preserve the original file layout,
so the emitted .d.ts does not compile and the only clue was an unrelated
ae-forgotten-export warning.
Such paths are now reported as ae-unresolved-import-path.
|
Phạm Mạnh Lực (@MLuc24) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
1 similar comment
|
Phạm Mạnh Lực (@MLuc24) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
Summary
Fixes #4507
Per Pete Gonzalez (@octogonz)'s conclusion on that issue — "Let's improve the error message: API Extractor could analyze the .d.ts output and identify import paths such as
../Barthat clearly don't make sense in a rollup, and report a more intuitive error message" — this adds a dedicatedae-unresolved-import-pathmessage for that case.Today an unresolvable inline
import()type is emitted into the rollup verbatim. The generated.d.tsthen contains a relative path that points nowhere, so it does not compile for consumers, and the only hint is anae-forgotten-exportwarning that names the symbol rather than the real problem.Details
In
DtsEmitHelpers.modifyImportTypeSpan, everything happens underif (referencedEntity). When the entity lookup fails there is noelse, so the span keeps its original text and the path survives into the rollup. The newelse ifinspects the import's module specifier and, when it is relative, reports the message against the same declaration.The check is deliberately narrow: only a specifier starting with
.is reported. A bare specifier that fails to resolve is a different situation (the rollup emits a realimportfor it), and the resolving case is untouched — see the negative test below.Two choices I would be happy to change: the message id name
ae-unresolved-import-path, and leaving it at the defaultwarningseverity rather than adding an entry toapi-extractor-defaults.json. Say the word and I will adjust either.I did not add a case under
build-tests/api-extractor-scenarios, because I could not regenerate the committed expected outputs locally (see below). Happy to add one if you would like it in this PR.How it was tested
Built the contrived example from the issue against
@microsoft/api-extractor7.58.12 —Bar.tsexporting an enum,foo/Foo.tsdeclaringexport type Foo = import('../Bar').Bar.A;, andindex.tsre-exportingFoo.Before, the rollup silently ends up unusable:
With this change applied, the cause is reported:
Negative test, to confirm it does not fire on inline imports that resolve normally — changing
Foo.tstoexport type Foo = import('../Bar').Bar;:Both runs were performed by applying this change to the published package's compiled output, since I could not run the monorepo's own
rush buildlocally. The API report incommon/reviews/api/api-extractor.api.mdwas updated by hand for the same reason, so it is worth confirming in CI that it matches.