testing-library / testing-library/testing-library-docs

Add Version Numbers to Library Interfaces

Open
#484 4 comments 7 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement nice to have 😎 organization 📂
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.