docs: develop API documentation strategy for package 'exports' fields #6090
Labels
chore
Maintenance or non-code work
docs:api
Additions, improvements, or fixes to API docs
status:in-progress
Work is in progress
Milestone
Comments
nicholasrice
added
status:triage
EisenbergEffect
added
chore
|
Related: microsoft/rushstack#3274 |
5 tasks
janechu
added
status:in-progress
janechu
added a commit
that referenced
this issue
Aug 1, 2024
# Pull Request ## 📖 Description This change points the `api-extractor` to the `di` and `context` export paths and adds this generated documentation to the documentation site. ### 🎫 Issues Resolves #6090 ## 👩💻 Reviewer Notes This is was a little fiddly as the `api-extractor` does not export export paths, additionally the way the `api-documentor` works assumes a single entry path. This is why if any additions need to be made to expose more export paths, we will need to edit 3 different files to get the documentation to show up on the documentation website. ## ✅ Checklist ### General <!--- Review the list and put an x in the boxes that apply. --> - [x] I have included a change request file using `$ yarn change` - [ ] I have added tests for my changes. - [x] I have tested my changes. - [x] I have updated the project documentation to reflect my changes. - [x] I have read the [CONTRIBUTING](https://github.com/microsoft/fast/blob/master/CONTRIBUTING.md) documentation and followed the [standards](https://github.com/microsoft/fast/blob/master/CODE_OF_CONDUCT.md#our-standards) for this project.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: