Relates to https://github.com/Qiskit/documentation/issues/6, which is
about docs. This PR only adds Prettier to our support code. We might
want to extend Prettier to docs in a follow up.
Having a consistent format is convenient and saves us time so that
humans don't have to manually move things around.
We have a non-trivial amount of TypeScript tooling, so this is worth
adding imo.
## Background
First part of https://github.com/Qiskit/documentation/issues/9. The docs
infrastructure expects MDX files, but `qiskit`, `qiskit-ibm-provider`,
and `qiskit-ibm-runtime` use Sphinx to generate their API references
from source code. So, @axelhzf created a pipeline to convert Sphinx
output to MDX.
We are moving that pipeline to live in open source since the API
references are also open source.
## What this PR does
This adds the `lib/sphinx` code and its tests. The code is copied over
without change, other than adding copyright headers. The PR also sets up
Jest.
A follow up PR will add the actual parsing script. I split up the PRs
since this adds non-trivial infrastructure like Jest, so to have a
smaller PR to review.
This code will be deleted from the internal repository once
https://github.com/Qiskit/documentation/issues/9 is complete and the
internal repository is consuming this one.
## Why Jest?
We use Playwright in https://github.com/Qiskit/qiskit_sphinx_theme, so I
considered using that too here for consistency.
But I stuck with the internal repo's decision to use Jest because
Playwright doesn't have an equivalent to `toMatchInlineSnapshot`. I
think Playwright is awesome, but we're never going to have Playwright
integration tests in this repository since we're not testing the docs
site itself in this repo, i.e. we don't need to spin up a server. Jest
is simpler for our unit tests.
Co-authored-by: Axel Hernández Ferrera <axelhzf@gmail.com>
In the closed source repository that consumes Qiskit/docs, we have this
same check for valid file metadata. It is useful to run it here too so
that we fail more eagerly.
Like the internal code, this uses TypeScript. It makes the code more
readable and better aligned with the internal code.
---------
Co-authored-by: Axel Hernández Ferrera <axelhzf@gmail.com>
Eric Arellano