testing-library / testing-library/testing-library-docs
Add Version Numbers to Library Interfaces
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 479
- Forks
- 740
- PR merge metrics
- No merged PRs in 30d
Description
Is your feature request related to a problem? Please describe.
I would love to be able to look at each documented interface of a library and learn which version of the library first supported it. The testing library libraries evolve very quickly, and I'd love to learn just by looking at the documentation which version of the library first supported the interface.
As an example, the screen interface shipped at the very end of 2019. I'd like to see what version of the given library supports that API. So if I am using @testing-library/react@9.3.0 I'd want to know if I have access to that feature or not.
Describe the solution you'd like
I'd like to see just a simple mention of what version the feature was first introduced, or alternatively a range of versions the feature supported (perhaps the API mutated between major versions, and you'd like to document the 9.0 - 11.0 behavior, but 12.0 would be different).
Describe alternatives you've considered
As I mentioned above, I see a couple ways this could be implemented. The shorter, simpler, solution would probably be to just list the version it was introduced in. An alternative would be to list the documentation for each permutation an interface undertook, for instance if a method added an argument to its parameters, then both permutations could be listed, perhaps with the deprecated API docs collapsed by default.
There's probably endless room for creativity with this.
Additional context
Thanks for considering it? :)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or documentation entry points are identified in the issue. First inspect the testing-library-docs structure and its interface documentation, then determine how version metadata and historical API variants should be represented; done means a defined, maintainable approach is documented and applied consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100