Deno: expose Request, Response globally

[JamesKyburz]

If fetch is available as a global should we not also expose Request, Response and friends like the browser environment does?

[kitsonk]

Request and Response are there, just not exposed globally.

Is there a use case for exposing them globally?

[JamesKyburz]

Request can be used by fetch instead of string and options.

However both Request and Response are global the browser environment.

Response would be nice to be able to mimic a Cloudflare worker locally (which has already been done in node)

[ry]

True, it is global in the browser. We ought to make it global in deno too.

[hayd]

Is there a way to generate a list of globals in chrome/Firefox/deno? That way could enumerate what is intentionally omitted vs what is awaiting implementation.

This would also be nice as documentation...

[kitsonk]

That would be a long long list. I think use case driven is still the best way. We are not going to implement name for example. 😄

[benjamingr]

I think there is merit in collaborating with the JS standard library spec proposal to see if Deno can have a say on what's exposed.

There are things the browser exposes it makes no sense for Deno to expose and vice versa.

[ry]

I didn't mean to suggest that Deno should have feature parity with browsers - that would be very difficult and beyond the scope of Deno. But where we provide a certain API (in this case fetch() and its associated Request) I think we shouldn't change how it's presented (in this case by having Request not be a global)

[benjamingr]

@ry true, though that might be confusing since the type Request will also be exported globally (right?) which might be confusing since request can be:

• An HTTP Request I'm making through fetch.
• An http request I received on the server.

The two are not necessarily a different type. (This was intentional in the design of fetch and service workers).

If projects like deno_std/http used Request (rather than ServerRequest) that would be cool since it'd align them with service workers and fetch.

[hayd]

It would be a long list but I imagine the vast majority will be labelled "intentionally omitted"!

[JamesKyburz]

Looking at the code it looks like ReadableStream could also be exposed?

[akircher]

I don't think ReadableStream is WhatWg compatible so think making it global right now might be more confusing than helpful. I haven't seen a reason why Deno doesn't use a WhatWg compatible API. If the Deno implementation doesn't plan on browser compatability here, I think it would be good to rename the Deno implementation or namespace it, so we don't paint ourselves in a corner and are unable to offer a spec based implementation in the future.

UPDATE: Not sure if am correct with this assessment. My opinion was based on an old thread.

[benjamingr]

@akircher see old discussion in https://github.com/denoland/deno/pull/387

[rsp]

For a list of JS global objects (i.e. those from the language spec, not the DOM) see:

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects

(but some of them are not exposed as real globals - see my unexposed module on npm for more info)

The host objects available in browser contexts are available on MDN here:

• https://developer.mozilla.org/en-US/docs/Web/API

(not everything on one place but a good start)

It makes sense to make everything global that is global in browsers, and nothing else (to avoid conflicts in the future)

[ry]

Fixed in #2253

[bartlomieju]

Looks like Response is implemented in //js/fetch.ts but it is still not exposed globally - see commented out code in globals.ts

CC @ry @kitsonk

[kitsonk]

My advice, don't comment it out. 😄