**What kind of change does this PR introduce?**
Better type inference.
**Did you add tests for your changes?**
~Not yet.~ Yes.
**If relevant, did you update the documentation?**
Not yet.
**Summary**
<!-- Explain the **motivation** for making this change. What existing
problem does the pull request solve? -->
<!-- Try to link to an open issue for more information. -->
Currently methods that return an element handle, i.e. `.$`,
`.waitForSelector` attempt to infer the node element type from the
selector string. However, this only works when the selector is an exact
match of the element tag, i.e. a selector `"a"` would be inferred as
`HTMLAnchorElement` . And not when the selector is complex, i.e.
selectors `"a#some-id"`, `div > a`, `a:nth-child(2)` would all fallback
on `Element`.
This is due to simply looking up the the selector in
`HTMLElementTagNameMap` and `SVGElementTagNameMap` without any attempt
to parse the selector string.
This PR is an attempt to do so.
**Does this PR introduce a breaking change?**
<!-- If this PR introduces a breaking change, please describe the impact
and a migration path for existing applications. -->
This could break existing incorrect assertions using the `as` keyword.
**Other information**
~This PR introduces a dependency on the `type-fest` package.~
This PR is far from complete (no tests, no docs). Put out early for
feedback and discussion.
Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com>
bef1061c06