fix(lib.deno_fetch.d.ts): Extend deprecated fetch() overload

[nayeemrmn]

#14113 broke https://deno.land/x/[email protected]/download.ts. The overload accepting URL should be all-inclusive or it won't accept an argument of type string | URL.

cc @kt3k

[lucacasonato]

LGTM, thanks!

[bebraw]

Would it be possible to add a test against this type somehow to avoid breaking it in the future? The regression broke Velociraptor and I imagine many projects depending on it were broken as a result (assuming CI usage here).

[nayeemrmn]

Would it be possible to add a test against this type somehow to avoid breaking it in the future? The regression broke Velociraptor and I imagine many projects depending on it were broken as a result (assuming CI usage here).

Maybe a regression test was deserved but in general there is no end to testing against types that way. It's as (un)likely to happen again as any obscure type def breakage.

[bebraw]

Maybe a regression test was deserved but in general there is no end to testing against types that way. It's as (un)likely to happen again as any obscure type def breakage.

Cool, good to know.

I remember seeing dependency oriented testing in Node space. The idea would be to test automatically if an upcoming change breaks dependents but that's a more general thing. I believe having this kind of capability in place would have caught this one, though, and it would probably catch others as well.

[KnorpelSenf]

That would indeed be very cool—before a release is performed, a hand-picked collection of deno.land/x modules is compiled. Is this feasible?