chore: allow testMany args to accept glob patterns

[netlify-team-account-1]

- Summary

(builds on #701)

This PR allows testMany variations to be passed in using patterns, and also adds a fancy recursive typescript type to give nice autocomplete to it.

- Test plan

• clone locally, try out autocomplete
• check if coverage stays the same

- A picture of a cute animal (not mandatory but encouraged)

[github-actions]

⏱ Benchmark results

largeDepsEsbuild: 13.5s

^  13.5s  
│   ┌──┐  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
└───┴──┴──>
     T    

Legend

• T (current commit): 13.5s

largeDepsZisi: 1m 14.6s

^ 1m 14.6s
│   ┌──┐  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
│   |▒▒|  
└───┴──┴──>
     T    

Legend

• T (current commit): 1m 14.6s

[netlify-team-account-1]

another demo:

Screen.Recording.2021-10-05.at.12.22.39.mov

[eduardoboucas]

Do we need these?

[netlify-team-account-1]

not neccessarily - (I used them for verifying that the type works as expected) - but they don't really hurt either, as they'll never be shipped and are used only be the editor

[eduardoboucas]

Sure, but why keep them if they're not doing anything?

[netlify-team-account-1]

good point. I've transformed them into type-level tests: https://github.com/netlify/zip-it-and-ship-it/pull/702/files/7f867da77363718059c2d449e91b8750f9926b86..3ef4abe7fa6e91e9f1657b4e18187ade118971f5

so now they work as documentation & tests :)
(since we haven't integrated our test suite with TypeScript yet, this won't do anything apart from being squiggly in the editor - but that's a start ^^)

[netlify-team-account-1]

this will likely need to be updated to support the todo: syntax introduced in #713

[eduardoboucas]

Sorry for taking so long to review this! It looks great, I would just say two things:

1. I always try to look for a solid reason to add another dependency, because that always carries a price. I understand that conditional-type-checks is being added to devDependencies, for which the price is considerably lower, but it's there nonetheless. Can you clarify why we need the functionality it introduces, since the types being asserted only exist in the context of the test suite?

2. Can we make this PR about adding the glob capability only, and then we decide which tests to convert to globs on a per-test basis, in separate PRs?

[netlify-team-account-1]

Can you clarify why we need the functionality it introduces, since the types being asserted only exist in the context of the test suite?

advanced typescript types are somewhat hard to understand. conditional-type-checks library gives some helper functions that allow expressing examples / test cases in-code. It's the type-level equivalent of a unit test, and acts both as a test and usage documentation. The hope is that it makes maintenance easier, and more accessible to devs that are new to TypeScript.

Can we make this PR about adding the glob capability only, and then we decide which tests to convert to globs on a per-test basis, in separate PRs?

Absolutely! done via 8660f19

[eduardoboucas]

advanced typescript types are somewhat hard to understand. conditional-type-checks library gives some helper functions that allow expressing examples / test cases in-code. It's the type-level equivalent of a unit test

I understand that, and type assertions feel like something we should do since the types are part of the API we offer to people consuming our libraries. But in this case we're adding type assertions to something that only exists in the context of the test suite, which I find a bit harder to understand.

The hope is that it makes maintenance easier, and more accessible to devs that are new to TypeScript.

I think the glob patterns in testMany is a nice-to-have convenience. If the logic that makes it possible is so complex that we need an additional library and type checks or else it becomes difficult to read and maintain, I would argue that we should probably reconsider whether it's worth adding.

[netlify-team-account-1]

I would argue that we should probably reconsider whether it's worth adding.

agreed!