Worker type definitions? about denoflare

[JustinGrote]

So using the "official" Cloudflare types is blocked on cloudflare/workers-types#199

until they fix how they present things, we're stuck with our own bespoke types. I've been working on some new well-documented types for the module worker syntax for my own use, which is a lot easier to encapsulate things than with the "globals" syntax, but yeah right now it's a bit painful.

[johnspurlock-skymethod]

Yea I've been maintaining my own types (in that cloudflare_workers_types.d.ts) from back before the official types file even existed.

Still find it useful as the the official one lags behind (esp for new cf alpha/beta services) and doesn't play nice with Deno.

I would like to have cloudflare_workers_types.d.ts reflect the current cloudflare production runtime as much as possible, so if you know of any specific differences that you are relying on in production, please raise them as issues/PRs on that file. Only thing to keep in mind is that denoflare's fakes/stubs/proxies may need to change along with any core type changes.

[johnspurlock-skymethod]

@ylxdzsw The latest release v0.5.10 allows the no-options version of KVNamespace.get. There are still advantages to maintaining a Deno-friendly and forward-looking version of these types, so our cloudflare_workers_types.d.ts isn't going anywhere any time soon.

[JustinGrote]

For anyone following, the @cloudflare/workers-types was updated so that it is now partially importable to avoid the conflicts that used to occur. I haven't tested it with denoflare but it may be easier to use at least a subset of the types now since they dont have to be global and things like "blob" should no longer conflict.

[JustinGrote]

To follow up, I tested and this works great using unpkg:

import { Request, ExecutionContext } from "https://unpkg.com/@cloudflare/[email protected]/experimental/index.ts"
import * as semVer from "https://deno.land/[email protected]/semver/mod.ts"

export default {
	async fetch() {
		const res = `Hello World! ${semVer.increment("1.2.3", "patch")}`
		console.log(res)
		return new Response(res);
	},
};

[johnspurlock-skymethod]

Nice, I could see migrating over to these piecemeal (re-exporting) in our types file where duplicative, and just keeping our file for the bleeding edge services that are not in workers-types yet.

I gave them some feedback about better jsdocs, and they are working on it. That's another advantage our types still have in some cases.