Several packages (namely fast-element and fast-ssr at this point) use 'exports' fields in their 'package.json' to separate package exports. For example, fast-ssr exposes DOM shim assets from @microsoft/fast-ssr/dom-shim and fast-element exposes utilities from @microsoft/fast-element/utilities.
Our existing API extractor setup only emits for a single export (the 'main' or '') exports, not these sub-path exports, which means only the main exports are currently surfaced to the documentation site. Once we extract API docs for all exports, we'll need a strategy to document where* the exports are coming from in a meaningful way on the documentation site; it will be confusing to consumers if they are inspecting API docs but they don't know which export path the asset comes form.
dzearing
commented
2 years ago
Several packages (namely fast-element and fast-ssr at this point) use 'exports' fields in their 'package.json' to separate package exports. For example, fast-ssr exposes DOM shim assets from
@microsoft/fast-ssr/dom-shimand fast-element exposes utilities from@microsoft/fast-element/utilities.Our existing API extractor setup only emits for a single export (the 'main' or '') exports, not these sub-path exports, which means only the main exports are currently surfaced to the documentation site. Once we extract API docs for all exports, we'll need a strategy to document where* the exports are coming from in a meaningful way on the documentation site; it will be confusing to consumers if they are inspecting API docs but they don't know which export path the asset comes form.