suggestion: make `@std/http` utilities cross-runtime

[LucienLeMagicien]

Is your feature request related to a problem? Please describe.

I would like to use @std/http/negotiation in Node using pnpm. negotiation is entirely self-contained, but jsr marks the whole @std/http module as Deno- and Bun-compatible only.

From a cursory look, most other utilities in @std/http (cookies, user_agent, status, server_sent_event_stream, ...) are also self-contained.

The dependencies for @std/http are from:

• unstable_signed_cookie depending on @std/encoding
• etag depending on @std/encoding
• unstable_file_server depending on file_server (below)
• file_server imports all the rest: @std/path, @std/fs, @std/media-types, @std/streams, @std/cli, @std/fmt, @std/net, @std/html, and ./etag above

There has been efforts in making some @std modules cross-runtime compatible (but from what I could find there is no global guideline on that):

• Port File System APIs in Deno namespace to @std/fs #6255 (currently pinned)
• suggestion(fs): make std/fs Node-compatible #4313 (referenced in the above)
• make @std/path cross-runtime #6164
• suggestion: make isWindows cross-runtime in @std/path #4914
• The Road to Stabilizing the Standard Library #4600

(search keywords: "cross-runtime", "node compatible")

The dependency graph in that last issue is relevant here:

http was the "widest" package dependency-wise, mostly from file_server.

The specific utility I want to use (negotiation) has been adapted from npm:negotiator, which has an open issue for migrating it to ES6: jshttp/negotiator#71. Since the work has already been done here, being able to use @std/http/negotiation from any runtime would also solve that issue.

Describe the solution you'd like

Some obvious solutions would be to split file_server to it's own module, or abstracting the Deno-specific APIs like what has been discussed in #4313.

If it's possible to "install" a specific path inside a module like @std/http/encoding from other package managers (I use pnpm), that'd work too. I couldn't find anything about that (I don't know the right keywords to search for), but I assume this has been considered and decided against, since running deno add jsr:@std/http/negotiation installs jsr:@std/http. Doing pnpm i jsr:@std/http/negotiation errors with a 404.

Having a blessed path to vendor specific files or functions (either from @std or from jsr generally) would also solve it for me. But I figure that'd be very package-specific and couldn't be generalized without a lot of tooling work. (I couldn't find much about vendoring related to jsr or @std.)

Describe alternatives you've considered

My current solution is to simply manually vendor the functions that I need. Ignoring file_server, this also avoids me the dependency on @std/encoding (from etag and unstable_signed_cookie) which I don't use.

I have considered using vendoring tools (vendorpull, vendir, git-vendor), some of which have options to pick specific files or ignore other paths.

Simply installing the whole http module via pnpm i jsr:@std/http also works (even if the module's jsr page doesn't show the pnpm option). Given that I don't use file_server, I won't hit the Deno-specific code. But this makes me pull 11 transitive dependencies that I don't use.

Assumedly I focus a lot on reducing dependencies. I understand that it might not be a goal or focus for everyone (or for jsr, or for @std — especially since the dependencies are on other @std modules only!)

---

Thanks for your time (and for the work on @std)!

[LucienLeMagicien]

Actually (since the utilities are already cross-compatible afaik), maybe a simpler solution is to mark the whole module as compatible and add a note about file_server, like how it has been done for @std/fmt here: #6647

Sorry, I somehow missed that issue when searching earlier!