feat(expect-type): add guards & asserts getters

[GerkinDev]

Test the type asserted or guarded by the subject function.

[codecov-io]

Codecov Report

Merging #231 (d14e705) into main (72630da) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #231   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           41        41           
  Lines          721       721           
  Branches       121       121           
=========================================
  Hits           721       721           

Impacted Files	Coverage Δ
packages/expect-type/src/index.ts	100.00% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 72630da...d14e705. Read the comment docs.

[mmkal]

Hi @GerkinDev, thanks for the PR!

I like this and would be happy to accept. I'm not so sure about lumping is T together with asserts is T though. What about two helpers:

expectTypeOf(myFunc).guard.toBeString()
expectTypeOf(myOtherFunc).assertion.toBeString()

That way we wouldn't need the GuardedType either. What do you think?

One other thing - if you run npm run lint -- --fix in the project folder, it'll automatically update the docs to include your new test. Worth giving the test a readme-appropriate name too.

[GerkinDev]

Well, in that case, and to stay consistent with your already existing getters, I'd name those functions guards & asserts, since you already have returns and resolves.

[GerkinDev]

Another thing: when running npm run lint -- --fix (or even just npm run lint), I have an error about rig not being found. Not really sure what I'm supposed to do. Am I supposed to link globally the content of tools/rig ? It would worth a small note in the install README (assuming you're planning to stay OS/PR welcoming).

[mmkal]

Hmm yes I suppose you're right re guards vs guardconsistency. The aim is to have the assertions read like a sentence though. And "expect type of foo guards to be string" makes a bit less sense than "expect type of foo guard to be string". I think there's similar inconsistency with .exclude and .extract.

While I have a (quick) think about that one, the lint problem: you're absolutely right, this repo is quite cryptic for OSS contributors. To get the various dev dependencies depends on rush. So I think what you'd need to do:

npm install --global @microsoft/rush
rush install # install all repo dependencies
rush build --to expect-type # build the repo
rush lint --to expect-type --fix

The first time you run these it might take a little while.

I'll add to the docs of each package in this monorepo soon.

[mmkal]

Shouldn't this be named isString?

[GerkinDev]

Dammit.

[GerkinDev]

Fixed in 30b3c4e

[GerkinDev]

Hey there,

Any news on this ?

[mmkal]

@GerkinDev sorry for the long delay. I'll merge and publish this in the next few days.

[GerkinDev]

No problem, I was off myself for a while ;)

[chriskrycho]

Just wanted to offer a drive-by "thank you!" for this as a user of the library. These are nice additions!