Closed scalvert closed 3 years ago
I realize this is a port, but since I'm reviewing anyways, should we add some explicit type annotations where some of the inference breaks down? I can add these.
@jeffersonking sounds good to me. I usually lazily ignore specific inference that can be resolved via my editor/IDE, but it does result in more complexity when reading code on Github, etc.
@scalvert Very much agree. It would only be in places where inference isn't working. I'll add a few and we can see if we like it.
Have we considered naming it toBeValidLog
and toBeValidResult
?
Intuitively, when named toMatchSomething(rhs)
, it feels odd not to have a RHS.
Note: I have also been dropping the "Sarif" prefix on names. Just a preference but the prefix proliferates very quickly.
This is an uncharacteristically large PR, which is not the norm (PRs should be more narrowly focused in the future!!). It's largely added in one PR due to the fact that it's ported from a separate project (Checkupjs), and as such was mostly implemented already.
This PR adds:
@microsoft/jest-sarif
packagetoMatchSarifLog
Please see the README for a comprehensive view of what's included.
Ultimately, this will form the basis for the test infrastructure in the forthcoming
sarif-builder
package, as this will allow us to create a powerful test infrastructure that can exercise testing SARIF schema fragments building.